数人が使用するUbuntu(10.10)マシンをセットアップしています。小規模オフィスの共有マシンです。その主な役割は、VirtualBoxで仮想マシンをホストし、Sambaでファイルを提供することです。
Sambaの場合、さまざまなユーザーが自分のワークステーションからSamba共有に接続できるように、いくつかのユーザーアカウントを設定する必要があります。ただし、複数の人が使用する仮想マシンの実行専用のアカウントもあります。時々、人々はこのアカウントで昇格された特権を必要とすることを試みます-これにより、Gnomeの「管理ユーザーのパスワードを入力してください」ダイアログがポップアップします。ただし、このダイアログはパスワードを要求します-マシンをセットアップしたとき、私のアカウントが最初に作成されたアカウントであるため、私だけがSudoパワーを付与されていると想定しているようです。
言うなれば、別のユーザーを「第一の管理者」に指定したいのですが、共有アカウントのユーザーにすることはできません。誰もがそのアカウントのパスワードを知っている必要があるため、その特権を厳しく制限したいのです。他の人に自分のパスワードを伝える方法がなく、自分でパスワードを入力するのに十分な頻度でサイトに立ち会うことはないので、それは私のアカウントにはなれません。しかし、canを直接行う人がいるので、/etc/sudoers
に追加しました。 Ubuntuに何かの特権を昇格する必要がある場合、最初にtheirアカウントを要求する必要があることを伝えるにはどうすればよいですか?
要約する:
/etc/sudoers
に入れることはできません。/etc/sudoers
に適切に入力されています-ボブはこのオフィスのボスです。su -
を使用して拡張管理タスクを行う習慣があります)。ここで目的の状態にするには、どのような構成変更が必要ですか?
まず、特権アクションが2つの異なるメカニズムを介して非ルートユーザーに許可されていることを指摘しておきましょう。
Sudo
PolicyKit
最初のものは、Sudo
を使用してコマンドを明示的に実行する場合、またはコマンドがgksu
でラップされているメニュー項目(Synaptic Package Managerなど)を使用する場合に使用されます。
この場合、必要なパスワードは、呼び出し元のユーザー、通常はログインしているユーザーのパスワードです。
2番目は、PolicyKit対応アプリケーションが特権アクションを実行しようとするときに使用されます。このような場合、アプリケーションは、アクションを実行できるかどうかをPolicyKit Local Authorityに(D-Bus経由で)尋ねます。 Local Authorityは、認証エージェントを介して、アクティブユーザーにその身元を証明するように依頼します。ダイアログウィンドウは次のようになります(残念ながら、イタリア語のテキストが表示されます:)
PolicyKitは、小さな黒い三角形とラベルDetailsから識別できます。ご覧のとおり、複数のユーザーがadmin
グループに属している場合、リストから認証に使用するユーザーを選択できます。
これをすべて考えると、Sudo
とPolicyKitの両方は、達成できる構成に関してはるかに複雑です。パスワードなしで実行できるアクション、特定のユーザーまたはグループのみが実行するアクションなどを構成できます。
あなたの質問に来ると、アプリケーションで使用されるメカニズムが現在のログインユーザーとは別にPolicyKitである場合、必要なパスワードはボブまたはアリス(正しく理解している場合は2人の管理ユーザー)のものであり、変更することができますリストから認証に使用するユーザー。
アプリケーションで使用されるメカニズムがSudo
である場合(GUIを介して実行される管理タスクの場合、これはそれほど頻繁ではなくなります)、認証のためにユーザーを選択するための即時かつ簡単な手段はありません。
明らかに、このような場合、Sudo
が最初の選択肢になります。主なポイントは、ほとんどの(実際の)管理者が/etc/sudoers
を可能な限り最大限に使用していないように見える(User_Alias
、Runas_Alias
、Host_Alias
、Cmnd_Alias
)。
ほとんどの管理者は、一部の既存ルールのみを使用してユーザーを追加するか、さらに悪いことに、Ubuntuセットアップで通常ルールが存在するSudo
グループにユーザーを追加します(%Sudo
...)。これは、もちろん、それぞれのユーザーに自由な統治とスーパーユーザーアカウントのフルパワーを与えます。
あなたのコメントを考える:
/etc/sudoers
に追加しました
私もあなたが可能な範囲でそれを使用しないと思います。
あなたのようなシナリオでは、ボブが制限されるいくつかのアクションを文字通りスクリプト化します。実際、これは、2人の特定のユーザーがホスト上の特定のKVMゲストを再起動できるようにするために、私が保守しているサーバーで行ったことです。スクリプトには、インタープリターへの絶対パスを持つハッシュバング(例:#!/bin/dash
の代わりに#!/usr/bin/env bash
)が含まれ、おそらく特権タスクに別の場所で使用されるシェル(/bin/dash
または/bin/sh
)。これらは単なる予防措置です。それ以外は、バイナリへのすべての絶対パスをハードコードし、可能な限り少ないパスを使用するようにします。例えば。 bash
/dash
を使用する場合、builtin
sよりもcommand
sを優先します(man bash
を参照)。変数に絶対パスを割り当て、その変数に基づいてプログラムを参照することで、これを保守可能にできます($VIRSH
の代わりに/usr/bin/virsh
)。可能であれば、外部スクリプトを呼び出す前に、外部スクリプトのコードを調べてください。特に特権コンテキストでそれらを呼び出す必要がある場合。私の場合、ユーザーはsshd
および公開キー認証を介してのみマシンに接続するため、ユーザーを特定のルートディレクトリと特定のSSHサブシステムに限定します。明らかにそれは必要ありません。
chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>
を確認して、root
以外の誰かがそれをいじるのを防ぎます。また、ターゲットバイナリで有効なsetuid
ビットとsetgid
ビットにも注意してください(find
を使用してそれらを見つけることができます)。しばらくの間、スクリプトが/usr/sbin/priv-action
にあると仮定しましょう。
/etc/sudoers
を編集します。 noexec
を使用して、明示的に許可されているバイナリ以外のバイナリも防止できます。ここで説明している設定だけでなく、実際には追加の設定がたくさんあります。必ずman sudoers
に相談してください。
sudoers
ファイルでユーザー(User_Alias
)に名前を付けることを好みますが、Group_Alias
(man sudoers
)または実際のシステムグループ(たとえば、 %Sudo
):
# The list is comma-separated: bob,alice,...
User_Alias LIMITED_ADMINS=bob
次に、コマンドエイリアスを追加して、その特定のスクリプトの実行を許可します。
# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias PRIV_ACTION=/usr/sbin/priv-action
最後に、bob
(またはLIMITED_ADMINS
の下にリストされているユーザー)がスクリプトを介して特権コマンドを実行できるようにするマジックラインがあります。
LIMITED_ADMINS ALL=(root) PRIV_ACTION
以前のエイリアス定義とは異なり、その行には説明が必要です。それでは、最初に「ユーザー仕様」の行の意味を調べてみましょう。ここでman sudoers
が役立ちます:
ユーザー仕様の基本構造は
who where = (as_whom) what
です。
例の行(ほとんどのUbuntuセットアップにあります):
root ALL=(ALL) ALL
これは、ユーザー名前付きroot
(#0
を使用してUID [0
]に結び付ける)は、すべてのホストで、任意のユーザーコンテキストで実行できることを示します。パスワードを求められます(デフォルトの動作を想定)。最後のNOPASSWD
の前にALL
タグを追加すると、root
がパスワードを要求されることなく同じことを行うことができます(例:root ALL=(ALL) NOPASSWD:ALL
)。 ALL
は、さまざまなエイリアスタイプの固有のワイルドカードエイリアスです。
しかし、ボブに戻ります。
LIMITED_ADMINS ALL=(root) PRIV_ACTION
bob
およびUser_Alias LIMITED_ADMINS
の他のリストされたメンバーを(すべてのホストで、ALL
の目的です)ユーザーroot
(グループが暗示されますが、与えられた、man sudoers
)Cmnd_Alias PRIV_ACTION
で与えられたコマンドを参照してください。それは良くなります。それでもこのスクリプトを作成すると仮定すると、さまざまなパラメーターを許可できるため、複数のスクリプトを作成する必要がなくなります。 /etc/sudoers
は喜んでシェルのようなワイルドカードを使用して、渡される引数の可能性を制限します。
私は一貫して、管理者がsudoers
を使用すべきではないことを発見しました。そのため、2つの書籍「Linux Server Hacks」と「Linux Server Hacks Volume Two」のそれぞれの「Hack」を高く評価しました。このすばらしい施設のより洗練された使用から始めました。
あらゆる種類の複雑なものを思い付くことができます-これはセキュリティ面で正確には役に立たないかもしれません-あなたの特定の場合の解決策ですが、/etc/sudoers
の基本的な語彙を話すと、非常に魔法の偉業を実行できます:)
注:気になる場合は、/etc/sudoers.d/
の下に新しいファイルを作成することもできます。これは、/etc/sudoers
に次の行が含まれていることを前提としています。
#includedir /etc/sudoers.d