権限認証機能の比較

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

実装の概要

マイクロソフトウィンドウズ
ユーザーアカウント制御プロンプトユーザーアカウント制御プロンプトダイアログボックスユーザーアカウント制御（ UAC）： Windows Vista以降のMicrosoft Windowsオペレーティングシステムに含まれているUACは、アプリケーションが管理者タスクを実行しようとしたときにユーザーに承認を求めます。 [ 1 ]
Runas : Windows 2000で導入されたコマンドラインツールおよびコンテキストメニュー機能。プログラム、コントロールパネルアプレット、またはMMC スナップインを別のユーザーとして実行できます。 [ 2 ] Runas は、同じく Windows 2000 で導入された「セカンダリログイン」 Windows サービスを利用します。 [ 3 ]このサービスは、別のユーザーとして実行されているアプリケーションが、ログインしているユーザーのデスクトップと対話できるようにする機能を提供します。これは、ドラッグアンドドロップ、クリップボード共有、その他の対話型ログイン機能をサポートするために必要です。
sudo : Windows 11 バージョン 24H2には Windows 版のsudoが付属しています。デフォルトでは有効になっていませんが、開発者向け設定ページで有効にすることができます。 [ 4 ]
macOS
認証macOSには認証ダイアログが含まれており、管理者タスクを実行する際にユーザーにパスワードの入力を求めます。これは本質的にsudoコマンドのグラフィカルなフロントエンドです。
UnixおよびUnixライク
GNOMEのPolicyKitPolicyKit/pkexec :使用中のデスクトップ環境に依存しないように設計された権限認証機能。GNOME [ 5 ]では既に採用されている。以前のシステムとは異なり、PolicyKitを使用するアプリケーションは、現在のユーザーの権限よりも高い権限で実行されることはない。代わりに、PolicyKitデーモンに間接的にリクエストを送信する。PolicyKitデーモンは、ルート権限で実行される唯一のプログラムである。
すsu : Unix用のコマンドラインツール。su (substitute user) を使用すると、ユーザーはユーザー名とパスワードを入力することで、端末を別のアカウントに切り替えることができます。ユーザー名を指定しない場合は、オペレーティングシステムのスーパーユーザーアカウント（「root」と呼ばれる）が使用され、システムへの完全な権限を持つログインシェルを迅速に取得できます。exit コマンドを実行すると、ユーザーは元のアカウントに戻ります。
須藤sudo :1980年頃に作成された[ 6 ] 。suに似た高度に設定可能なUnixコマンドラインツールであるが、特定のユーザーがルートシェルを生成したりルートのパスワードを要求したりすることなくルート権限でプログラムを実行できるようにする。 [ 7 ]
gksudoGKSuとGKsudo：suとsudoのGTK+グラフィカルフロントエンド。[ 8 ] GKsuは、サポートされているアプリケーションがルート権限を必要とするアクションを実行する必要があるときに自動的に起動します。su / sudoの代わりにPolicyKitを使用する代替手段「 gksu PolicyKit」が、GNOMEの一部として開発されています。[ 9 ]
クデスkdesu : KDEのsuコマンドのQtグラフィカルフロントエンド。[ 10 ]
kdesudokdesudo : Kubuntu 7.10以降、Kubuntuでkdesuに代わるsudoのQtグラフィカルフロントエンド。[ 11 ]
クツスktsuss : ktsuss は「suをシンプルに、愚かに」の略で、suのグラフィカルバージョンです。このプロジェクトの理念は、シンプルさとバグのなさを維持することです 。
ハチスbeesu : Red Hatベースのオペレーティングシステムにおいてgksuに代わるsuコマンドのグラフィカルフロントエンド。主にRHELとFedora向けに開発されている。[ 12 ]
doas : OpenBSD 5.8 (2015 年 10 月) 以降のsudo の代替

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

偽造/傍受されたユーザー入力

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

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

偽の認証ダイアログ

もう一つのセキュリティ上の考慮事項は、悪意のあるソフトウェアが、正当なセキュリティ確認要求を装ったダイアログを表示する可能性があることです。ユーザーが偽のダイアログを正当なものと思い込み、認証情報を入力すると、悪意のあるソフトウェアはユーザーのパスワードを入手してしまいます。セキュアデスクトップなどの機能が無効化されている場合、悪意のあるソフトウェアはそのパスワードを利用してより高い権限を取得する可能性があります。

UAC はWindows 11 でセキュア アテンション シーケンスを要求し、ログインのなりすましを回避するために、ユーザーに最初にCtrl+Alt+Deleteキーを押して資格情報を入力するように求めます。
  • ユーザビリティ上の理由からデフォルトの動作ではありませんが、UAC は認証プロセスの一部としてユーザーにCtrl+Alt+Del キー(セキュア アテンション シーケンスと呼ばれる) を押すことを要求するように設定できます。Windows だけがこのキーの組み合わせを検出できるため、この追加のセキュリティ対策を要求することで、偽装されたダイアログが正当なダイアログと同じように動作することを防ぐことができます。[ 17 ]たとえば、偽装されたダイアログではユーザーにCtrl+ Alt+ を押すように要求されない場合Delがあり、ユーザーはそのダイアログが偽物だと気付く可能性があります。あるいは、ユーザーが Ctrl+Alt+Del キーを押したときに、UAC 確認ダイアログではなく、Ctrl+Alt+Del で通常表示される画面が表示されます。そのため、ユーザーは、そのダイアログが悪意のあるソフトウェアにパスワードを入力するように誘導するためのものかどうかを判断できます。
  • GNOMEでは、PolicyKitはシステムの設定に応じて異なるダイアログを使用します。例えば、指紋リーダーを搭載したシステムの認証ダイアログは、指紋リーダーを搭載していないシステムの認証ダイアログとは見た目が異なる場合があります。アプリケーションはPolicyKitの設定にアクセスできないため、どのダイアログが表示されるか、そしてどのように偽装するかを知る方法がありません。[ 18 ]

ユーザビリティの考慮

これらの実装で考慮されたもう 1 つの点は、使いやすさです。

別の管理者アカウント

  • su では、ユーザーは少なくとも 2 つのアカウント (通常使用アカウントと、rootなどのより高い権限を持つアカウント) のパスワードを知っている必要があります。
  • sudo、kdesu、gksudo はよりシンプルなアプローチを採用しています。これらのプログラムでは、ユーザーは特定の管理タスクへのアクセス権限を事前に付与されますが、それらの権限でアプリケーションを実行するには、明示的に承認を与える必要があります。ユーザーはスーパーユーザーや他のアカウントのパスワードではなく、自分のパスワードを入力します。
  • UACとAuthenticateは、これら2つの概念を1つに統合したものです。これらのプログラムを使用すると、管理者はプログラムがより高い権限で実行されることを明示的に承認できます。管理者以外のユーザーには、管理者のユーザー名とパスワードの入力が求められます。
  • PolicyKitはこれらのいずれかのアプローチを採用するように設定できます。実際には、ディストリビューションがいずれか1つを選択します。

会話のシンプルさ

  • アプリケーションに管理者権限を与えるために、sudo、[ 19 ] gksudo、およびAuthenticateは管理者にパスワードの再入力を促します。
  • UACでは、標準ユーザーとしてログインしている場合、アプリケーションに管理者権限を付与するたびに管理者名とパスワードを入力する必要があります。一方、Administratorsグループのメンバーとしてログインしている場合は、（デフォルトでは）毎回パスワードを再入力するのではなく、確認または拒否を選択するだけで済みます（パスワードを再入力することもできます）。デフォルトの方法はよりシンプルですが、安全性も低くなります。[ 17 ]ユーザーがコンピューターをロックせずに物理的に離れると、別の人物が近づいてきてシステムの管理者権限を取得できる可能性があるためです。
  • PolicyKit では、ユーザーがパスワードを再入力するか、他の認証手段 (指紋など) を提供する必要があります。

資格情報の保存

  • UAC は、プログラムを昇格するために呼び出されるたびに、承認を求めます。
  • sudo、[ 7 ]、 gksudo、kdesuは、プログラムを昇格させる際に毎回ユーザーにパスワードの再入力を求めません。代わりに、起動時に一度だけパスワードの入力を求めます。ユーザーが一定時間（sudoのデフォルトは5分[ 7 ]）管理者権限を使用していない場合、ユーザーは再びパスワードを入力するまで標準ユーザー権限に制限されます。
sudo のアプローチは、セキュリティとユーザビリティのトレードオフです。一方で、ユーザーは一連の管理者タスクを実行する際にパスワードを一度入力するだけで済み、タスクごとにパスワードを入力する必要がなくなります。しかし同時に、タイムアウト前にこれらのコマンドのいずれかをプレフィックスとして指定した場合、その tty で実行されるすべてのプログラム（sudoの場合）またはターミナルで実行されていないすべてのプログラム（ gksudo および kdesu の場合）に管理者権限が付与されるため、攻撃を受ける可能性が高くなります。セキュリティを重視するユーザーは、sudoが使用された各 tty または pts から when コマンドを使用することで、管理者権限を必要とするタスクを完了した後に一時的な管理者権限を削除できます（ pts の場合、ターミナルエミュレータを閉じるだけでは不十分です）。kdesu の同等のコマンドは です。gksudo には同じことを行うオプションはありませんが、ターミナルインスタンス以外で実行することで（例えば、 + 「アプリケーションの実行」ダイアログボックスで「ターミナルで実行」のチェックを外すなど）、目的の効果が得られます。sudo -kkdesu -ssudo -kAltF2
  • Authenticate はパスワードを保存しません。ユーザーが標準ユーザーの場合、ユーザー名とパスワードを入力する必要があります。ユーザーが管理者の場合、現在のユーザー名が既に入力されているため、パスワードを入力するだけで済みます。ユーザー名を変更して別のユーザーとして実行することも可能です。
アプリケーションは一度だけ認証を必要とし、権限が必要な時に要求されます。一度「昇格」されると、アプリケーションを終了して再起動するまで、再度認証する必要はありません。
ただし、認証には様々なレベルがあり、これらは「権限」と呼ばれます。要求されている権限は、パスワードの下にある「詳細」の横にある三角形を展開することで確認できます。通常、アプリケーションはsystem.privilege.adminを使用しますが、セキュリティのために低い権限、あるいはより高いアクセスが必要な場合は高い権限など、別の権限が使用される場合もあります。アプリケーションが持つ権限がタスクに適していない場合、権限レベルを上げるために再度認証が必要になることがあります。
  • PolicyKit は、これらのいずれかのアプローチを採用するように構成できます。

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

オペレーティングシステムがユーザーに認証を求めるタイミングを判断するには、アプリケーションまたはアクションが、昇格された権限を必要とすることを自ら認識している必要があります。技術的には、そのような権限を必要とする操作が実行された瞬間にユーザーに認証を求めることは可能ですが、タスクの完了途中で権限を求めるのは必ずしも理想的ではありません。ユーザーが適切な資格情報を提供できない場合、タスクを最後まで実行できず、管理者権限を要求する前に行われた作業が元に戻される可能性があります。

Microsoft WindowsのコントロールパネルやMac OS Xの環境設定パネルなどのユーザーインターフェースの場合、正確な権限要件はシステムにハードコードされており、適切なタイミングで（例えば、管理者のみが閲覧できる情報を表示する前など）、ユーザーに認証ダイアログが表示されます。オペレーティングシステムによって、アプリケーションがセキュリティ要件を識別するための方法は異なります。

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

参照

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

参考文献

  1. ^ 「ユーザーアカウント制御の概要」 . Microsoft . 2006年10月2日. 2011年8月22日時点のオリジナルよりアーカイブ。2007年3月12日閲覧。
  2. ^ 「Runas」 . Windows XP 製品ドキュメント. Microsoft . 2007年3月13日閲覧。
  3. ^ "「RunAs の基本 (および中級) トピック」。Aaron Margosis の WebLog。MSDNブログ。2004 年 6 月 23 日。2007年 3 月 13 日取得。
  4. ^ 「Windows用Sudo」 . 2025年7月22日.
  5. ^ 「PolicyKitについて」 . PolicyKit言語リファレンスマニュアル. 2007年. 2012年2月18日時点のオリジナルよりアーカイブ。2017年11月3日閲覧。
  6. ^ Miller, Todd C. 「A Brief History of Sudo」 . 2007年2月22日時点のオリジナルよりアーカイブ。 2007年3月12日閲覧。
  7. ^ a b c Miller, Todd C. 「Sudo in a Nutshell」2007年7月1日閲覧。
  8. ^ 「GKSuホームページ」。
  9. ^ 「Gnome wiki の gksu PolicyKit」。
  10. ^ Bellevue Linux (2004-11-20). 「KDE suコマンド」 . 2007年2月2日時点のオリジナルよりアーカイブ。2007年3月12日閲覧。
  11. ^ Canonical Ltd. (2007-08-25). 「GutsyGibbon/Tribe5/Kubuntu」. 2007年9月18日閲覧。
  12. ^ beesu Archived 2011-07-25 at the Wayback Machineで詳細を読むことができ、 Kojiからダウンロードすることも
  13. ^ 「gksu - Gtk+ suフロントエンドのLinuxマニュアルページ」 。 2011年7月15日時点のオリジナルよりアーカイブ。2007年8月14日閲覧。
  14. ^ 「セキュアデスクトップ上のユーザーアカウント制御プロンプト」 UACBlog Microsoft 2006年5月3日2007年3月4日閲覧。
  15. ^ 「gksu: マウス/キーボードをロックするだけではキーロギングの防止には不十分」。
  16. ^ 「ptrace 保護」。
  17. ^ a b Allchin, Jim (2007年1月23日). 「セキュリティ機能 vs. 利便性」 . Windows Vistaチームブログ. Microsoft . 2007年3月12日閲覧。
  18. ^ 「認証エージェント」 2007年. 2012年2月18日時点のオリジナルよりアーカイブ。2017年11月15日閲覧。
  19. ^ Miller, Todd C. 「Sudoersマニュアル」 。 2007年3月12日閲覧。
  20. ^ 「最小権限環境でのアプリケーション開発者向けベストプラクティスとガイドライン」 MSDN 、 Microsoft 、 2007年3月15日閲覧。
  21. ^ 「Windows Vista のユーザー アカウント制御の理解と構成」 . TechNet . Microsoft . 2007 年 3 月 15 日閲覧。
  22. ^ 「アクセシブルなUACプロンプト」 . Windows Vistaブログ. Microsoft. 2008年1月27日時点のオリジナルよりアーカイブ。2008年2月13日閲覧。
「 https://en.wikipedia.org/w/index.php?title=Comparison_of_privilege_authorization_features&oldid=1322311824」より取得