Ubuntuが管理ユーザーのパスワードを要求するとき、どの管理ユーザーを要求するかをどのように決定しますか？

数人が使用するUbuntu（10.10）マシンをセットアップしています。小規模オフィスの共有マシンです。その主な役割は、VirtualBoxで仮想マシンをホストし、Sambaでファイルを提供することです。

Sambaの場合、さまざまなユーザーが自分のワークステーションからSamba共有に接続できるように、いくつかのユーザーアカウントを設定する必要があります。ただし、複数のユーザーが使用する仮想マシンの実行専用のアカウントもあります。時々、人々はこのアカウントで昇格された特権を必要とすることを試みます-これにより、Gnomeの「管理ユーザーのパスワードを入力してください」ダイアログがポップアップします。ただし、このダイアログはパスワードを要求します。マシンをセットアップしたとき、私のアカウントが最初に作成されたアカウントであるため、sudo権限を付与されたユーザーは自分だけであると想定されているようです。

別のユーザーを「第一の管理者」に指定したいのですが、誰でもそのアカウントのパスワードを知っている必要があるため、共有アカウントユーザーにすることはできません。他の人に自分のパスワードを伝える方法がないため、自分のアカウントにはできません。自分でパスワードを入力するのに十分な頻度でサイトに立ち会うことはありません。ただし、これを直接行うことができる人がいるので、それらをに追加しました/etc/sudoers。どのように私はそれが何かのために権限を昇格する必要があるときに、それが求めるべきであるとのUbuntuを伝えることができます彼らの最初のアカウント？

要約する：

• マシンのアカウント：アリス、ボブ、キャロル、デイブ、エリザ。
• Ubuntuがインストールされたとき、Aliceはインストールプロセス中に追加された最初のユーザーでした。
• 「デイブ」は、実際には多くの人が使用するアカウントであり/etc/sudoers、パスワードは一般に知られているために参加できません。
• ボブはGnomeの「管理」アカウントに設定されており、適切に入力されています/etc/sudoers-ボブはこのオフィスのボスです。
• Bob、Carol、Eliza、またはDaveとしてログインしているときに、昇格された特権を必要とするアクションが試行されると、システムはBobの資格情報を要求する必要があります。
• アリスとしてログインしているときに昇格された特権を必要とするアクションが試行されると、システムはアリスの資格情報を要求する必要があります（ただし、アリスは一種のbuckaroo sysadminであり、su -拡張管理タスクを使用する習慣があります）。

ここで目的の状態を実現するには、どのような設定変更が必要ですか？

まず、2つの異なるメカニズムを介して非rootユーザーに特権アクションが許可されていることを指摘しましょう。

1. sudo

2. PolicyKit

最初のものは、コマンドを明示的に実行する場合、sudoまたはコマンドがラップされたメニュー項目gksu（Synaptic Package Managerなど）を実行する場合に使用されます。
この場合、必要なパスワードは、呼び出し元のユーザー、通常はログインしているユーザーのパスワードです。

2つ目は、PolicyKit対応アプリケーションが特権アクションを実行しようとするときに使用されます。このような場合、アプリケーションは、アクションを実行できるかどうかをPolicyKit Local Authorityに（D-Bus経由で）尋ねます。Local Authorityは、認証エージェントを介して、アクティブユーザーにその身元を証明するように依頼します。ダイアログウィンドウは次のようになります（残念ながら、イタリア語のテキストが表示されます:)

PolicyKitは、小さな黒い三角形とラベルDetailsから識別できます。ご覧のとおり、adminグループに複数のユーザーがいる場合は、リストから認証に使用するユーザーを選択できます。

これらすべてsudoを考慮すると、実現可能な構成に関して、両方とPolicyKitははるかに複雑です。パスワードなしで実行できるアクション、特定のユーザーまたはグループのみが実行できるアクションなどを構成できます。

あなたの質問に来ると、アプリケーションで使用されるメカニズムがPolicyKitである場合、現在ログインしているユーザーとは別に、必要なパスワードはBobまたはAlice（正しく理解している場合は2人の管理者ユーザー）であり、変更できますリストから認証に使用するユーザー。

アプリケーションで使用されるメカニズムがsudo（GUIを介して実行される管理タスクの場合、頻度が低下している）場合、認証のためにユーザーを選択するための即時かつ簡単な手段はありません。

明らかに、sudoそのような場合には私にとって最初の選択でしょう。主なポイントは、ほとんどの（実際の）管理者が実際に使用していないということであるように思われる/etc/sudoers最大限可能な範囲（へUser_Alias、Runas_Alias、Host_Alias、Cmnd_Alias）。

ほとんどの管理者は、既存のルールの一部のみを使用してユーザーを追加するか、さらに悪いことに、sudoUbuntuセットアップで通常ルールが存在するグループにユーザーを追加するだけ%sudoです（...）。もちろん、これはそれぞれのユーザーに自由な統治とスーパーユーザーアカウントのフルパワーを与えます。

あなたのコメントを考える：

に追加しました /etc/sudoers

私もあなたが可能な範囲でそれを使用しないと思います。

あなたのようなシナリオでは、ボブが制限されるいくつかのアクションを文字通りスクリプト化します。実際、これは、2人の特定のユーザーがホスト上の特定のKVMゲストをリブートできるようにするために、私が管理しているサーバーで行ったことです。スクリプトには、インタプリタへの絶対パス（例：#!/bin/dashではなく#!/usr/bin/env bash）を含むハッシュバングが含まれ、おそらく特権タスク（/bin/dashまたは/bin/sh）で他の場所で使用されるシェルで実行されます。これらは単なる予防措置です。それ以外は、バイナリへのすべての絶対パスをハードコードし、可能な限り少数を使用するようにします。たとえば、bash/ dashを使用する場合は、builtinsよりもsを優先しcommandます（を参照man bash）。変数に絶対パスを割り当て、その変数に基づいてプログラムを参照することにより、これを維持可能にできます（$VIRSHの代わりに/usr/bin/virsh）。可能であれば、外部スクリプトを呼び出す前に、外部スクリプトのコードを調べてください。特に特権コンテキストでそれらを呼び出す必要がある場合。私の場合、ユーザーは特定のルートディレクトリと特定のSSHサブシステムに限定され、ユーザーはsshd公開キー認証を介してのみマシンに接続します。明らかにそれは必要ありません。

適切な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。

ファイルにユーザー（User_Alias）の名前を付けるsudoersようになりましたが、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

これは、（UIDに結び付けるために使用される）という名前 のユーザーは、すべてのホスト上で任意のユーザーコンテキストで実行できますが、パスワードの入力を求められます（デフォルトの動作を想定）。最後のタグの前にタグを追加すると、パスワードを要求されることなく同じことを行うことができます（次のように）。は、さまざまなエイリアスタイプの固有のワイルドカードエイリアスです。root#00NOPASSWDALLrootroot ALL=(ALL) NOPASSWD:ALLALL

しかし、ボブに戻って：

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

で指定されたコマンドをユーザー（グループが暗示されますが、与えられる可能性があります、参照）として（bobおよびUser_Alias LIMITED_ADMINSすべてのホストで）の実行を許可します。それは良くなります。このスクリプトを記述することを前提として、さまざまなパラメーターを許可することにより、複数のスクリプトを記述することを回避できます。シェルのようなワイルドカードを喜んで使用して、渡される引数の可能性を制限します。ALLrootman sudoersCmnd_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

Unix / Linuxにはスーパーユーザーが1人だけいて、その名前はrootですが、sudoersはrootになることができるユーザーです。グループを使用する必要があります。

newgrp admins

そして、そのグループにユーザーを割り当てます。

chgrp alice admins

次に、グループがユーザーであるかのように、adminsグループをsudoers構成ファイルに追加します。

更新

または、管理グループに任意のユーザーを追加できます。

chgrp alice admin