特権認証機能の比較

セキュリティ上の大きな懸念事項の一つは、悪意のあるアプリケーションがキー入力やマウスクリックをシミュレートし、セキュリティ機能を欺いたり偽装したりして、悪意のあるアプリケーションに高い権限を付与する可能性があることです。

• ターミナルベースのクライアント（スタンドアロンまたはデスクトップ/GUI内）を使用する場合：suとsudoはターミナルで実行されるため、入力の偽装に対して脆弱です。もちろん、ユーザーがマルチタスク環境（つまり、シェル内で単一ユーザーのみ）を実行していない場合は、これは問題になりません。ターミナルウィンドウは通常、ユーザーに対して通常のウィンドウとして表示されるため、インテリジェントなクライアントまたはクライアントとして使用されるデスクトップシステムでは、ユーザーはデスクトップ上の他のマルウェアが入力を操作、シミュレート、またはキャプチャすることを防ぐ責任を負わなければなりません。
• オペレーティングシステムに密接に統合されたGUI/デスクトップを使用する場合：一般的に、デスクトップシステムは、パスワードやその他の認証を要求する前に、すべての一般的な入力手段をロックまたは保護し、傍受、改ざん、またはシミュレートできないようにします。

• PolicyKit ( GNOME - Xサーバーにすべてのキーボードとマウスの入力をキャプチャするように指示します。PolicyKitを使用する他のデスクトップ環境では、独自のメカニズムを使用する場合があります。
• gksudo - デフォルトではキーボード、マウス、ウィンドウフォーカスを「ロック」し、^{[ 17 ]}実際のユーザー以外がパスワードを入力したり、確認ダイアログに干渉したりすることを防止します。
• UAC (Windows) - デフォルトではセキュア デスクトップで実行され、悪意のあるアプリケーションが「許可」ボタンをクリックしたり、確認ダイアログに干渉したりするのを防ぎます。^{[ 18 ]} このモードでは、ユーザーのデスクトップは暗く表示され、操作できません。

gksudo の「ロック」機能または UAC のセキュア デスクトップのいずれかが侵害または無効化された場合、悪意のあるアプリケーションは、キーストローク ロギングを使用して管理者のパスワードを記録することによって管理者権限を取得できます。または、UAC の場合、管理者として実行されている場合は、「許可」ボタンのマウス クリックを偽装できます。このため、音声認識もダイアログとの対話が禁止されています。gksuパスワード プロンプトは特別な権限なしで実行されるため、悪意のあるアプリケーションは、 straceツールなどを使用してキーストローク ロギングを実行できることに注意してください。^{[ 19 ]} (ptrace は後のカーネル バージョンで制限されました) ^{[ 20 ]}

もう一つのセキュリティ上の懸念事項は、悪意のあるソフトウェアが正規のセキュリティ確認要求に見せかけたダイアログを偽装できることです。ユーザーが偽のダイアログを正規のものだと信じて認証情報を入力した場合、悪意のあるソフトウェアはユーザーのパスワードを知ることになります。セキュアデスクトップなどの機能が無効になっている場合、悪意のあるソフトウェアはそのパスワードを使ってより高い権限を取得する可能性があります。

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

• su では、ユーザーは少なくとも 2 つのアカウントのパスワードを知っている必要があります。通常使用するアカウントと、rootなどのより高い権限を持つアカウントです。
• sudo、kdesu、gksudoはよりシンプルな方法を採用しています。これらのプログラムでは、ユーザーは特定の管理タスクへのアクセス権限が事前に付与されていますが、アプリケーションがその権限で実行されるためには、明示的に承認する必要があります。ユーザーはスーパーユーザーや他のアカウントのパスワードではなく、自身のパスワードを入力します。
• pfexec は、ユーザーアカウントの代わりに「プロファイル」を使用してユーザーに権限を付与します。^{[ 15 ]}各プロファイルは、特定のコマンドと認証を実行するためのアクセス権を付与し、そのプロファイルが実行する機能にちなんで命名されます。（たとえば、ユーザーは、およびを実行できるようにするために、「監査管理」プロファイルを使用できる必要があり/usr/sbin/auditます/usr/sbin/auditconfig。^{[ 16 ]}）
• UACとAuthenticateは、これら2つの概念を1つに統合したものです。これらのプログラムを使用すると、管理者はプログラムをより高い権限で実行することを明示的に承認できます。管理者以外のユーザーは、管理者のユーザー名とパスワードの入力を求められます。
• PolicyKitは、これらのアプローチのいずれかを採用するように構成できます。実際には、配布元がいずれかを選択します。

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

• UACは、プログラムの権限昇格が呼び出されるたびに、承認を求めます。
• sudo [ ^{7 ]} gksudoおよびkdesu は、プログラムの^権限 昇格のために呼び出されるたびにユーザーにパスワードの再入力を求めません。代わりに、ユーザーは起動時に一度だけパスワードを求められます。ユーザーが一定期間管理者権限を使用していない場合 (sudo のデフォルトは 5 分^{[ 7 ]} )、ユーザーはパスワードを再度入力するまで再び標準ユーザー権限に制限されます。

sudo のアプローチは、セキュリティと使いやすさのトレードオフです。一方では、一連の管理者タスクを実行するために、ユーザーは各タスクごとにパスワードを入力するのではなく、パスワードを一度だけ入力すれば済みます。しかし同時に、タイムアウト前にこれらのコマンドのいずれかがプレフィックスとして付加された、その tty で実行されるすべてのプログラム ( sudoの場合) またはターミナルで実行されていないすべてのプログラム (gksudo と kdesu の場合) が管理者権限を取得するため、攻撃対象領域が大きくなります。セキュリティを重視するユーザーは、sudoが使用された各 tty または pts からコマンドを使用して、必要なタスクを完了したら一時的な管理者権限を削除できます(pts の場合、ターミナル エミュレータを閉じるだけでは不十分です)。kdesu の同等のコマンドは です。gksudo には同じことを行うオプションはありませんが、ターミナル インスタンス内で実行しない (たとえば、 [+アプリケーションの実行] ダイアログボックスで [ターミナルで実行] のチェックを外す) とすれば、目的の効果が得られます。sudo -kkdesu -ssudo -kAltF2

• Authenticateはパスワードを保存しません。ユーザーが標準ユーザーの場合は、ユーザー名とパスワードを入力する必要があります。ユーザーが管理者の場合は、現在のユーザー名が既に入力されているため、パスワードを入力するだけで済みます。ユーザー名は変更可能で、別のユーザーとして実行することもできます。

アプリケーションは一度だけ認証を必要とし、その認証はアプリケーションが権限を必要とする際に要求されます。一度権限が昇格されると、アプリケーションは終了して再起動されるまで、再度認証する必要はありません。

ただし、認証にはさまざまなレベルがあり、これらは「権限」と呼ばれます。要求された権限は、パスワードの下にある「詳細」の横にある三角形を展開することで確認できます。通常、アプリケーションは system.privilege.admin を使用しますが、セキュリティのために低い権限、より高いアクセスが必要な場合は高い権限など、別の権限が使用される場合もあります。アプリケーションが持つ権限がタスクに適していない場合、権限レベルを上げるために再度認証が必要になることがあります。

• PolicyKitは、これらのどちらのアプローチを採用するように設定できます。