web-dev-qa-db-ja.com

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

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

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

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

要約する：

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

ここで目的の状態にするには、どのような構成変更が必要ですか？

rootadministrationusers
11
Brighid McDonnell

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

  1. Sudo

  2. PolicyKit

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

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

enter image description here

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

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

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

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

9
enzotib

明らかに、このような場合、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を使用する場合、builtinsよりもcommandsを優先します（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
6
0xC0000022L