権限認可機能の比較

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ

多くのコンピューターオペレーティング システムは、悪意のあるソフトウェアがコンピューター システムを危険にさらすのに十分な権限を取得するのを防ぐために、セキュリティ機能を採用しています。DOSWindows NT (およびその子孫) より前のWindows実装、CP/M-80、および Mac OS X より前のすべての Mac オペレーティング システムなど、そのような機能を欠いているオペレーティング システムでは、実行が許可されたユーザーのカテゴリは 1 つしかありませんでした。なんでも。個別の実行コンテキストを使用すると、複数のユーザーがプライベート ファイルを保存したり、複数のユーザーが同時にコンピューターを使用したり、悪意のあるユーザーからシステムを保護したり、悪意のあるプログラムからシステムを保護したりできます。最初のマルチユーザー セキュア システムはMulticsでした、1960 年代に開発が開始されました。マルチタスキング セキュリティ コンテキストがx86コンシューマ マシン に導入されたのは、80 年代後半から 90 年代前半のUNIXBSDLinux、およびNTまででした。

実装の紹介

マイクロソフトウィンドウズ
ユーザー アカウント制御プロンプトユーザー アカウント制御プロンプト ダイアログ ボックス ユーザー アカウント制御( UAC ): Windows Vista以降のMicrosoft Windowsオペレーティング システムに
含まれているUACは、アプリケーションが管理者タスクを実行しようとしたときに、ユーザーに承認を求めるプロンプトを表示します。[1]
Runas : Windows 2000
で導入されたコマンド ライン ツールおよびコンテキスト メニュー動詞で、プログラム、コントロール パネル アプレット、またはMMC スナップインを別のユーザーとして実行できます。[2] Runas は、同じく Windows 2000 で導入された「Secondary Login」 Windows サービスを利用します。 [3]このサービスは、別のユーザーとして実行されているアプリケーションが、ログインしているユーザーのデスクトップと対話できるようにする機能を提供します。これは、ドラッグ アンド ドロップ、クリップボード共有、およびその他の対話型ログイン機能をサポートするために必要です。
マックOS
認証する Mac OS Xには、管理者タスクを実行するためにユーザーにパスワードの入力を求める [認証] ダイアログが含まれています。sudoこれは基本的に、コマンド のグラフィカルなフロントエンドです。
Unix および Unix ライク
GNOME の PolicyKit PolicyKit/pkexec :使用中のデスクトップ環境から独立するように設計され、 GNOME
で既に採用されている特権認証機能[4]以前のシステムとは対照的に、PolicyKit を使用するアプリケーションは、現在のユーザーの特権を超える特権で実行されることはありません。代わりに、 root として実行される唯一のプログラムである PolicyKitデーモンに間接的に要求を行います。
す su : Unix
用のコマンド ライン ツールsu (代替ユーザー) を使用すると、ユーザーは、別のアカウントのユーザー名とパスワードを入力して、ターミナルを別のアカウントに切り替えることができます。ユーザー名が指定されていない場合は、オペレーティング システムのスーパーユーザーアカウント ("root" と呼ばれる) が使用されるため、システムへの完全な権限を持つログインシェルをすばやく取得できます終了コマンドを発行すると、ユーザーは自分のアカウントに戻ります。
須藤 sudo :
1980 年頃に作成された[5] sudoは、 suに似た高度に構成可能な Unix コマンド ライン ツールですが、特定のユーザーが root シェルを生成したり root のパスワードを要求したりすることなく、root 権限でプログラムを実行できるようにします。[6]
ぐくすど GKSuおよびGKsudo : suおよびsudoへの
GTK+ グラフィカル フロントエンド[7]サポートされているアプリケーションがルート権限を必要とするアクションを実行する必要がある場合、GKsuは自動的に起動します。su / sudoではなくPolicyKitを使用する" gksu PolicyKit " が、 GNOMEの一部として開発されています。[8]
です kdesu : KDEのsuコマンドに対する
Qtグラフィカルフロントエンド[9]
kdesudo kdesudo : Kubuntu 7.10 以降、Kubuntu でkdesu を置き換えsudo
の Qt グラフィカル フロントエンド。[10]
クツス ktsuss :
ktsussは " keep the su simple , s tupid "略で、 suグラフィカル バージョンですプロジェクトの考え方は、シンプルでバグのないままにすることです。
べーす beesu : Red Hatベースのオペレーティング システムでgksuを置き換えたsuコマンド
のグラフィカル フロントエンド。主にRHELFedora向けに開発されています。[11]
doas : OpenBSD 5.8 (2015 年 10 月)
以降の sudo の置き換え

セキュリティに関する考慮事項

ユーザー入力の改ざん/傍受

セキュリティ上の主な考慮事項は、悪意のあるアプリケーションがキーストロークやマウス クリックをシミュレートする能力です。これにより、セキュリティ機能をだまして、悪意のあるアプリケーションにより高い権限を付与するようになりすますことができます。

  • 端末ベースのクライアント (スタンドアロンまたはデスクトップ/GUI 内) を使用する: suおよびsudoは端末で実行され、なりすまし入力に対して脆弱です。もちろん、ユーザーがマルチタスク環境を実行していない場合 (つまり、シェル内の単一ユーザーのみ)、これは問題になりません。ターミナル ウィンドウは通常、通常のウィンドウとしてユーザーに表示されるため、クライアントとして使用されるインテリジェント クライアントまたはデスクトップ システムでは、デスクトップ上の他のマルウェアが入力を操作、シミュレート、またはキャプチャすることをユーザーが責任を持って防止する必要があります。
  • オペレーティング システムに緊密に統合された GUI/デスクトップを使用する:通常、デスクトップ システムは、パスワードやその他の認証を要求する前に、すべての一般的な入力手段をロックまたは保護して、傍受、操作、またはシミュレートできないようにします。
  • PolicyKit ( GNOME -すべてのキーボードとマウスの入力をキャプチャするようにXサーバーに指示します。PolicyKit を使用する他のデスクトップ環境では、独自のメカニズムが使用される場合があります。
  • gksudo - デフォルトでは、キーボード、マウス、およびウィンドウのフォーカスを「ロック」し[12] 、実際のユーザー以外がパスワードを入力したり、確認ダイアログを妨害したりできないようにします
  • UAC (Windows) - デフォルトではSecure Desktopで実行され、悪意のあるアプリケーションが [許可] ボタンのクリックをシミュレートしたり、確認ダイアログを妨害したりするのを防ぎます。[13] このモードでは、ユーザーのデスクトップは薄暗く表示され、操作できません。
gksudo の「ロック」機能または UAC の Secure Desktop のいずれかが侵害されるか無効になっている場合、悪意のあるアプリケーションは、キーストローク ログを使用して管理者のパスワードを記録することにより、管理者権限を取得する可能性があります。または、管理者として実行している場合の UAC の場合は、[許可] ボタンのマウス クリックをスプーフィングします。このため、音声認識もダイアログと対話することは禁止されています。[要出典] gksu パスワード プロンプトは特別な権限なしで実行されるため、悪意のあるアプリケーションはstraceツールなどを使用してキーストローク ロギングを行うことができることに注意してください。[14] (ptrace は後のカーネル バージョンでは制限されていました) [15]

偽の認証ダイアログ

もう 1 つのセキュリティ上の考慮事項は、正当なセキュリティ確認要求のように見えるダイアログを偽装する悪意のあるソフトウェアの機能です。ユーザーが偽のダイアログに資格情報を入力すると、そのダイアログが正当なものであると考え、悪意のあるソフトウェアはユーザーのパスワードを知ることができます。Secure Desktop または同様の機能が無効になっている場合、悪意のあるソフトウェアはそのパスワードを使用してより高い権限を取得する可能性があります。

  • 使いやすさの理由から既定の動作ではありませんが、UACは、認証プロセスの一部としてユーザーがCtrl+Alt+Delを押す必要があるように構成されている場合があります(セキュア アテンション シーケンスと呼ばれます)。このキーの組み合わせを検出できるのは Windows のみであるため、この追加のセキュリティ対策を要求すると、偽装されたダイアログが正規のダイアログと同じように動作するのを防ぐことができます。[16]たとえば、スプーフィングされたダイアログは、ユーザーに Ctrl+Alt+Del を押すように要求しない可能性があり、ユーザーはダイアログが偽物であることに気付く可能性があります。または、ユーザーが Ctrl+Alt+Del を押すと、UAC 確認ダイアログの代わりに、通常は Ctrl+Alt+Del で表示される画面が表示されます。したがって、ユーザーは、ダイアログがユーザーをだまして悪意のあるソフトウェアにパスワードを提供させようとする試みであるかどうかを知ることができます。
  • GNOME では、PolicyKitはシステムの構成に応じて異なるダイアログを使用します。たとえば、指紋リーダーを搭載したシステムの認証ダイアログは、指紋リーダーを搭載していないシステムの認証ダイアログとは異なる場合があります。アプリケーションは PolicyKit の構成にアクセスできないため、どのダイアログが表示されるか、どのように偽装するかを知る方法がありません。[17]

ユーザビリティに関する考慮事項

これらの実装に加えられたもう 1 つの考慮事項は、使いやすさです。

別の管理者アカウント

  • suでは、少なくとも 2 つのアカウント (通常使用のアカウントと、rootなどのより高い権限を持つアカウント) のパスワードをユーザーが知っている必要があります。
  • sudokdesu、およびgksudoは、より単純なアプローチを使用します。これらのプログラムでは、ユーザーは特定の管理タスクへのアクセスを許可されるように事前構成されていますが、それらの特権で実行するアプリケーションを明示的に承認する必要があります。ユーザーは、スーパーユーザーまたは別のアカウントのパスワードではなく、自分のパスワードを入力します。
  • UACAuthenticateは、これら 2 つのアイデアを 1 つにまとめたものです。これらのプログラムを使用すると、管理者はプログラムをより高い特権で実行することを明示的に承認します。非管理者は、管理者のユーザー名とパスワードの入力を求められます。
  • PolicyKitは、これらのアプローチのいずれかを採用するように構成できます。実際には、ディストリビューションはいずれかを選択します。

ダイアログのシンプルさ

  • アプリケーションに管理者権限を付与するために、sudo[18] gksudo、およびAuthenticateは、管理者にパスワードの再入力を求めます。
  • UACでは、標準ユーザーとしてログインした場合、ユーザーは、アプリケーションに昇格された権限を付与する必要があるたびに、管理者の名前とパスワードを入力する必要があります。ただし、管理者グループのメンバーとしてログインすると、(デフォルトでは) 毎回パスワードを再入力するのではなく、単純に確認または拒否します (オプションですが)。デフォルトのアプローチはより単純ですが、安全性も低くなります[16]。ユーザーがコンピューターをロックせずに物理的に離れた場合、別の人が立ち上がってシステムの管理者権限を取得する可能性があるためです。
  • PolicyKitでは、ユーザーがパスワードを再入力するか、その他の認証手段 (指紋など) を提供する必要があります。

資格情報の保存

  • UACは、プログラムを昇格するために呼び出されるたびに承認を求めます。
  • sudo[6] gksudo、およびkdesuは、プログラムを昇格するために呼び出されるたびにユーザーにパスワードの再入力を求めません。代わりに、ユーザーは最初に一度パスワードを求められます。ユーザーが一定期間管理者権限を使用していない場合 (sudo のデフォルトは 5 分[6] )、パスワードを再度入力するまで、ユーザーは再び標準ユーザー権限に制限されます。
sudo のアプローチは、セキュリティと使いやすさのトレードオフです。一方では、ユーザーはパスワードを 1 回入力するだけで、一連の管理者タスクを実行できます。タスクごとにパスワードを入力する必要はありません。しかし同時に、その tty で実行されるすべてのプログラム (sudo の場合) または端末で実行されないすべてのプログラム (gksudo および kdesu の場合) は、タイムアウト前にこれらのコマンドのいずれかがプレフィックスとして付けられているため、攻撃の対象領域が大きくなります。特権。セキュリティ意識の高いユーザーは、sudo -ksudo が使用された各 tty または pts からコマンドを使用して、必要なタスクを完了すると、一時的な管理者特権を削除できます (pts の場合、端末エミュレーターを閉じるだけでは十分ではありません)。kdesu の同等のコマンドは次のとおりです。kdesu -s. 同じことを行う gksudo オプションはありません。ただし、sudo -kターミナル インスタンス内で実行していない場合 (たとえば、Alt + F2 [アプリケーションの実行] ダイアログ ボックスを使用して、[ターミナルで実行] のチェックを外した場合) は、目的の効果が得られます。
  • 認証はパスワードを保存しません。ユーザーが標準ユーザーの場合、ユーザー名とパスワードを入力する必要があります。ユーザーが管理者の場合、現在のユーザーの名前は既に入力されており、パスワードを入力するだけで済みます。この名前は、別のユーザーとして実行するように変更できます。
アプリケーションは認証を 1 回だけ要求し、アプリケーションが特権を必要とするときに要求されます。「昇格」すると、アプリケーションを終了して再起動するまで、アプリケーションを再度認証する必要はありません。
ただし、権限と呼ばれるさまざまなレベルの認証があります。要求された権限は、パスワードの下の「詳細」の横にある三角形を展開することで表示できます。通常、アプリケーションは system.privilege.admin を使用しますが、セキュリティのための下位権限や、より高いアクセスが必要な場合は上位権限など、別の権限を使用することもできます。アプリケーションが持っている権限がタスクに適していない場合、アプリケーションは権限レベルを上げるために再度認証する必要がある場合があります。
  • PolicyKitは、これらのアプローチのいずれかを採用するように構成できます。

管理者権限が必要な場合の特定

オペレーティング システムがいつユーザーに承認を求めるかを知るために、アプリケーションまたはアクションは、昇格された特権が必要であることを識別する必要があります。そのような権限を必要とする操作が実行された瞬間にユーザーにプロンプ​​トを表示することは技術的に可能ですが、タスクの完了の途中で権限を要求することは多くの場合、理想的ではありません。ユーザーが適切な資格情報を提供できなかった場合、管理者権限を要求する前に行った作業を元に戻す必要がありました。

Microsoft Windows のコントロール パネルや Mac OS X の環境設定パネルなどのユーザー インターフェイスの場合、適切なタイミングでユーザーに認証ダイアログが表示されるように、正確な権限要件がシステムにハードコードされています (たとえば、管理者だけが見る必要がある情報を表示する前など)。異なるオペレーティング システムは、アプリケーションがセキュリティ要件を特定するための異なる方法を提供します。

  • sudoは、すべての権限認証情報を 1 つの構成ファイルにまとめます。このファイルに/etc/sudoersは、ユーザーのリストと、それらのユーザーが使用できる特権アプリケーションとアクションが含まれています。sudoers ファイルの文法は、コマンドライン パラメーターに制限を設けるなど、さまざまなシナリオに対応できる柔軟性を備えています。たとえば、次のように、root アカウントを除くすべてのユーザーのパスワードを変更するためのアクセス権をユーザーに付与できます。
pete ALL = /usr/bin/passwd [Az]*, !/usr/bin/passwd ルート
  • ユーザー アカウント制御は、ヒューリスティック スキャンと "アプリケーション マニフェスト" の組み合わせを使用して、アプリケーションに管理者特権が必要かどうかを判断します。[19] マニフェスト ( .manifest ) ファイルは、Windows XP で初めて導入されたもので、アプリケーションと同じ名前で ".manifest" という接尾辞が付いたXMLNotepad.exe.manifestファイルです。アプリケーションが開始されると、マニフェストが参照され、アプリケーションのセキュリティ要件に関する情報が確認されます。たとえば、次の XML フラグメントは、アプリケーションが管理者アクセスを必要とするが、アプリケーション外のユーザー デスクトップの他の部分への自由なアクセスは必要としないことを示します。
<security> 
    <requestedPrivileges> 
        <requestedExecutionLevel  level= "requireAdministrator"  uiAccess= "false"  /> 
    </requestedPrivileges> 
</security>
マニフェスト ファイルは、埋め込みリソースとしてアプリケーションの実行可能ファイル自体にコンパイルすることもできます。主に下位互換性のために、ヒューリスティック スキャンも使用されます。この一例は、実行可能ファイルのファイル名を見ることです。「Setup」という単語が含まれている場合、実行可能ファイルはインストーラーであると見なされ、アプリケーションの起動前に UAC プロンプトが表示されます。[20]
UAC は、署名済みの実行可能ファイルと署名されていない実行可能ファイルからの昇格要求も区別します。前者の場合、発行元が「Windows Vista」であるかどうか。プロンプトの色、アイコン、および文言は、それぞれのケースで異なります。たとえば、実行可能ファイルが署名されていない場合よりも、署名されていない場合に警告の意味をより強く伝えようとします。[21]
  • PolicyKitを使用するアプリケーションは、認証を求めるときに特定の権限を要求し、PolicyKit はアプリケーションに代わってそれらのアクションを実行します。認証する前に、ユーザーはどのアプリケーションがアクションを要求し、どのアクションが要求されたかを確認できます。

も参照

  • 権限昇格、セ​​キュリティ エクスプロイトの一種
  • 最小特権の原則、セキュリティ設計パターン
  • Privileged Identity Management、特権アカウントを管理する方法論
  • 特権パスワード管理、特権 ID 管理と同様の概念:
    • つまり、定期的に特権パスワードをスクランブルします。
    • 安全で可用性の高いボールトにパスワード値を保存します。
    • これらのパスワードがいつ、どのように、誰に開示されるかに関するポリシーを適用します。

参考文献

  1. ^ "ユーザー アカウント制御の概要" . マイクロソフト2006-10-02。2011 年 8 月 22 日にオリジナルからアーカイブされまし2007 年3 月 12 日閲覧
  2. ^ 「ルナス」 . Windows XP 製品ドキュメントマイクロソフト2007 年3 月 13 日閲覧
  3. ^ "「RunAs」の基本 (および中間) トピック」 . Aaron Margosis の WebLog . MSDN ブログ. 2004-06-23 . 2007-03-13取得.
  4. ^ 「PolicyKitについて」 . PolicyKit 言語リファレンス マニュアル2007. 2012-02-18のオリジナルからのアーカイブ2017 年11 月 3 日閲覧
  5. ^ Miller, Todd C. "A Brief History of Sudo" . 2007-02-22にオリジナルからアーカイブ2007 年3 月 12 日閲覧
  6. ^ a b c Miller, Todd C. "Sudo in a Nutshell" . 2007 年7 月 1 日閲覧
  7. ^ 「GKSu ホームページ」 .
  8. ^ "Gnome wiki の gksu PolicyKit" .
  9. ^ Bellevue Linux (2004-11-20). 「KDE su コマンド」 . 2007-02-02にオリジナルからアーカイブ2007 年3 月 12 日閲覧
  10. ^ Canonical Ltd. (2007-08-25). 「GutsyGibbon/Tribe5/Kubuntu」. 2007 年9 月 18 日閲覧
  11. ^ beesu Archived 2011-07-25 の詳細については、 Wayback Machineで読み、Koji からダウンロードできます
  12. ^ "gksu - Gtk+ su フロントエンド Linux Man Page" . 2011-07-15にオリジナルからアーカイブ2007 年8 月 14 日閲覧
  13. ^ "Secure Desktop でのユーザー アカウント制御プロンプト" . UACBブログマイクロソフト2006-05-03 . 2007 年3 月 4日閲覧
  14. ^ "gksu: マウス/キーボードのロックではキーロギングから保護するには不十分" .
  15. ^ "ptrace 保護" .
  16. ^ a b オールチン、ジム(2007-01-23). 「セキュリティ機能と利便性」 . Windows Vista チーム ブログマイクロソフト2007 年3 月 12 日閲覧
  17. ^ 「認証エージェント」 . 2007. 2012-02-18のオリジナルからのアーカイブ2017 年 11月15 日閲覧
  18. ^ Miller, Todd C. "Sudoers Manual" . 2007 年3 月 12 日閲覧
  19. ^ 「最小特権環境でのアプリケーションに関する開発者のベスト プラクティスとガイドライン」 . MSDN . マイクロソフト2007 年3 月 15 日閲覧
  20. ^ "Windows Vista でのユーザー アカウント制御の理解と構成" . テックネットマイクロソフト2007 年3 月 15 日閲覧
  21. ^ "アクセス可能な UAC プロンプト" . Windows Vista ブログ. マイクロソフト。2008-01-27にオリジナルからアーカイブ2008 年2 月 13 日閲覧