sudoを使用したスーパーユーザ特権の設定
- 概要
sudo設定の基本を理解し、sudoを使用してスーパーユーザ特権を委任する方法を習得します。この記事は、sudoの詳細な設定情報を提供するものであり、包括的で安全なsudoポリシーを構築する方法についてのアドバイスを提供するものではありません。セキュリティ関連のポリシーは非常に複雑であり、ポリシーの作成対象の環境によって大きく異なります。- 目的
コマンドによっては、管理者特権または
root特権が必要なものがあります。sudoを使用すると、そのようなコマンドを実行する特権を特定のユーザやグループに委任できます。- 所要時間
この記事の理解には20分ほどを要します。最初の
sudo設定ルールの作成に要する時間は数分たらずですが、環境全体で機能するsudo設定を確立するには、設定の複雑さに応じて相応の時間を要します。- 目標
sudo設定の基本的な特性を理解します。sudo設定の一般的な使用例に対処します。sudoセットアップでユーザ、ユーザグループ、およびエイリアスを操作する方法を習得します。sudoのベストプラクティスとトラブルシューティングを理解します。- 要件
sudoの基本的な理解。root特権。通常のユーザとしてsudoを使用する方法についてはhttps://documentation.suse.com/smart/systems-management/html/sudo-run-commands-as-superuser/index.htmlを参照してください。
1 sudoの設定の概要 #
sudoは、特定のユーザまたはグループにスーパーユーザ特権を安全かつ効率的に委任する手段を提供します。
Linuxシステムでは、特定の操作にroot特権または管理者特権が必要です。ホームユーザが自身のシステムを管理する場合、スーパーユーザ特権を委任する必要はありません。このシナリオでは、管理者と通常のユーザが同一人物であるためです。ただし、システムが複数のユーザ、グループ、およびホストで構成される大規模な環境の一部になるとすぐに、誰がどこで何を実行できるかを常に制御することが不可欠になります。同時に、すべてのユーザとグループにそのタスクを実行するために必要な特権を付与することも重要になります。
sudo-policy-wheel-auth-selfパッケージで実装された新しいポリシーでは、wheelグループは、ユーザがユーザパスワードでrootになれるかどうかを追跡するために使用されます。Agamaインストーラによって作成された最初のユーザはwheelグループに追加されます。
さらに、sudoコマンドを実行すると、次のようになります。
wheelグループに属している場合は、ユーザパスワードを入力するよう求められます。wheelグループに属していない場合は、rootパスワードを入力するよう求められます。
sudoは以下を提供します。
- システムセキュリティの強化
sudoを使用すると、ユーザ、グループ、ホスト、およびコマンドをきめ細かく制御できるため、侵入者やシステムユーザによる悪意のある損害や偶発的な損傷を受けるリスクが減り、システムのセキュリティが向上します。- 優れた監査証跡
これは、ユーザが特権を切り替えるたびにシステムのログに表示され、このユーザが昇格された特権で実行したすべての操作を遡って追跡できます。
root固有のタスクを委任する方法sudoを使用すると、システム管理者は、単一のユーザやグループがrootパスワードを入力したり、rootアカウントに切り替えたりすることなく、特定のタスクを実行できるようにすることができます。
2 カスタムsudo設定の作成 #
簡単なカスタムのsudo設定例を構築し、それを段階的に拡張する方法について習得します。グループを作成し、エイリアスを使用することで、カスタム設定の簡潔性と効率性を維持します。
SUSE Linux Enterprise Server for SAP applications15から移行する場合、/etc/sudoersファイルが存在します。/etc/sudoersファイルが存在する場合、/usr/etc/sudoersファイルは無視されます。ユーザが/etc/sudoersファイルを大幅に変更していない限り、/etc/sudoers.d/ディレクトリの設定が引き続き読み込まれます。
SUSE Linux Enterprise Server for SAP applications15から移行する場合、/etc/sudoersファイルを変更していないユーザはそのファイルを削除することをお勧めします。ユーザが/etc/sudoersファイルを修正した場合、修正したファイルを/etc/sudoers.dディレクトリに移動してから削除してください。
以下で紹介するルールの例はデモンストレーションのみを目的としています。これらのルール例を利用して、sudo設定ファイルの一般的な構文を理解してください。実際の環境では、このルール例をそのまま使用しないでください。環境の複雑さを反映していないからです。
2.1 sudoの設定でのベストプラクティス #
まず、sudo設定を維持するための基本ルールについて説明します。
/etc/sudoers.d/ディレクトリを編集するには、必ずvisudo -fコマンドを使用するsudoの設定の変更では、どの場合もvisudoコマンドを使用する必要があります。visudoは、sudo設定ファイルを編集することができ、基本的な構文チェックを実行して、設定がそのまま機能できるようにする、オーダーメイドツールです。sudoの設定に不備があると、ユーザが自身のシステムからロックアウトされることがあります。- 必ず
/etc/sudoers.d/にカスタム設定を作成する カスタム設定は、
sudoによって取得できるように、/etc/sudoers.d/ディレクトリに置く必要があります。カスタム設定ファイルに記述した設定は、/usr/etc/sudoersのデフォルト設定よりも優先されます。- 設定が読み取られる順序にいつでも注意する
カスタム設定が確実に正しい順序で読み取られるように数字のプレフィクスを付加します。先頭に0を付加してファイルの読み取り順序を指定します。これにより、たとえば
01_myfirstconfigは10_myotherconfigよりも前に解析されます。順番に読み取られる複数のディレクティブを設定したファイルで、これらの各ディレクティブに記述された情報が互いに矛盾していると、最後に読み込まれたディレクティブが適用されます。- 必ずわかりやすいファイル名を使用する
設定ファイルの機能がわかるようなファイル名を使用します。
sudoのセットアップで想定している動作を追跡する際に、この措置が効果的です。
2.2 ユーザ固有の設定ファイルの作成 #
通常のユーザ(tux)が、rootパスワードではなく自身のパスワードを使用して、useraddコマンドを使用できるように、sudoの設定ファイルを作成します。
新しいユーザ固有のディレクティブを保持するカスタム設定ファイルを作成します。そのためには、システム管理者(
root)としてvisudoを起動します。番号付けと説明的な名前の両方を使用します。#visudo -f /etc/sudoers.d/02_usermanagementこの
sudo設定を適用する環境全体でtuxが/usr/sbin/useraddバイナリを実行できるようにするルールを作成します。tux1 ALL2 = /usr/sbin/useradd3
ユーザまたはグループを指定します。ユーザは、名前または
#UIDで一覧にし、グループは、%GROUPNAMEで一覧にします。複数の項目はコンマで区切って記述します。エントリを無効にするには!を使用します。ホストを1つまたはコンマで区切って複数指定します。完全修飾ホスト名またはIPアドレスを使用します。すべてのホストにこの設定をグローバルに適用するには
ALLを追記します。適用しない場合は!を使用します。実行可能ファイルを1つまたはコンマで区切って複数指定します。各ファイルの指定では次のルールに留意します。
-
/usr/sbin/useradd 追加オプションを追記しない場合は、実行可能なすべての
useraddコマンドを実行できます。-
/usr/sbin/useradd -c 明示的にオプションを指定すると、そのオプションのみが適用されます。上記で指定したユーザは、これ以外のオプションを利用できません。
-
/usr/sbin/useradd "" オプションを指定せずに
useraddの呼び出しのみができるようにします。
上記の例では、すべてのオプションとサブコマンドを許可するか、またはセキュリティ上の理由から数個に制限したいと考えていますが、ユーザによるオプションの指定を一切禁止することは、この状況では無意味です。
-
設定を保存し、エディタを終了して、2番目のシェルを開き、
sudoが新しい設定に従うかどうかをテストします。
2.3 項目のグループ化によるカスタム設定の作成 #
指定したユーザのグループがrootパスワードを必要とせずにuseraddコマンドを実行できるように、例1「ユーザ固有の設定ファイルの作成」の設定を変更します。また、このグループで使用できるコマンドのリストにusermodとuserdelを追加します。
この設定例を変更するには、
visudoを使用してシステム管理者として設定を開きます。#visudo /etc/sudoers.d/02_usermanagementコンマ区切りで記述した複数のユーザをルールに追加します。
tux, wilber ALL = /usr/sbin/useradd
ここで記述したユーザが複数のコマンドを実行できるようにするには、それらのコマンドをコンマ区切りで指定します。
tux, wilber ALL = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
設定を保存し、エディタを終了して、2番目のシェルを開き、
sudoが新しい設定に従うかどうかをテストします。
2.4 エイリアスの適用による設定の簡潔化 #
エイリアスを使用して、例2「項目のグループ化によるカスタム設定の作成」のカスタム設定の簡素化を進めます。項目をグループ化することはある程度役立ちますが、ユーザ、コマンド、およびホストのグローバルエイリアスを使用することが、クリーンで無駄のないsudo設定を保つための最も効率的な方法です。
リストの代わりにエイリアスやグループを使用する方が、セットアップの変更に対処する上ではるかに良い方法です。グループからユーザが離れる場合は、独立したカスタム設定ファイルをすべて確認するのではなく、エイリアス宣言ファイル内のグローバルUser_Alias宣言からそのユーザを削除するだけですみます。他のタイプのエイリアス(Host_Alias、Cmnd_Alias、およびRunas_Alias)についても、同じ手順が適用されます。
グローバルエイリアス定義を保持する新しいファイルを作成します。
#visudo /etc/sudoers.d/01_aliases次の行を追加して、
TEAMLEADERSエイリアスを作成します。User_Alias TEAMLEADERS = tux, wilber
次の行を追加して、
USERMANAGEMENTエイリアスを作成します。Cmnd_Alias USERMANAGEMENT = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
変更を保存し、
visudoを終了します。システム管理者として
visudoを起動して、設定ファイル例を次のように編集します。#visudo -f /etc/sudoers.d/02_usermanagement前のルールを削除し、上記で定義したエイリアスを使用する次のルールに置き換えます。
TEAMLEADERS ALL = USERMANAGEMENT
設定を保存し、エディタを終了して、2番目のシェルを開き、
sudoが新しい設定に従うかどうかをテストします。
3 sudoのパスワードプロンプトのタイムアウト変更 #
コマンドごとにrootパスワードの入力を求められることなく、root特権を必要とするコマンドを実行する際のタイムアウト設定を変更する方法について説明します。
先頭がsudoであるコマンドを初めて実行するときにrootパスワードの入力を求められます。このパスワードは一定期間有効です。この期間が経過すると、パスワードの入力を再度求められます。root特権を必要とするコマンドを実行する際のこのタイムアウトを延長または短縮するには、sudo設定ファイルを次のように変更します。rootパスワードの入力を求めるプロンプトは、wheelグループに属していないユーザ向けであることを知っておくことが重要です。
root特権にパスワードを使用しないアクセスを無制限に許可しないようにします
セキュリティ上の理由から、root特権に無制限のアクセスを許可しないでください。代わりに、侵入者によるrootアカウントの悪用を防止するために適切なタイムアウトを設定します。
sudoのパスワードプロンプトのタイムアウト変更 #システム管理者として、次のようにtimestamp設定を指定した新しい
sudo設定ファイルを作成します。#visudo --f=/etc/sudoers.d/timestamp_timeoutrootパスワードによって正しく認証されると、この設定ファイルが開きます。編集を有効にし、行
timestamp_timeout=を追加します。timestampの値を入力します。たとえば、タイムアウトを3分に短縮するには次のように指定します。
Defaults timestamp_timeout=3
タイムアウトを0に設定していると、
sudoコマンドを実行するたびにrootパスワードの入力を求められます。変更を保存して、ファイルを閉じます。
sudo設定ファイルを作成し、sudoコマンドの実行のタイムアウト設定を短くしました。
4 root特権によるシェルの起動 #
sudo -sコマンドまたはsudo -iコマンドを使用して、永続的なroot特権でシェルを起動します。どちらのコマンドでも、rootパスワードの入力を一度だけ求められます。ユーザがwheelグループに属している場合、自身のパスワードの入力を求められることを知っておくことが重要です。そうでない場合は、rootパスワードの入力を求められます。
4.1 sudo -sとsudo -iの違い #
rootとしてコマンドを実行するたびにsudoの入力が必要であると煩雑な作業になることがあります。代わりに、いずれかの組み込み機能を使用して永続的なroot特権でシェルを起動できます。この方法では次の2つのコマンドオプションを利用できます。
sudo -sでは、現在のユーザの環境でシェルを起動し、いくつかの特権制御手段も使用できます。このコマンドを実行するにはrootパスワードを入力します。sudo -i: クリーンな環境で対話型ログインシェルとしてシェルを起動します。このコマンドを実行するにはrootパスワードを入力します。
どちらのコマンドでも、シェルは新しい環境で起動し、ユーザはrootとしてログインします。起動したシェルで実行する各コマンドは、パスワードの再入力を必要としない昇格した特権で実行されます。この環境はシェルを閉じると終了するため、別のsudoコマンドでは再度パスワードを入力する必要があります。
4.2 sudo -sによるシェルの起動 #
sudo -sコマンドでは対話型の非ログインシェルが起動します。rootパスワードによって正しく認証されると、以降のすべてのコマンドは昇格した特権で実行されます。
SHELL環境変数またはユーザのデフォルトのシェルで、どのシェルを開くかを指定します。この変数が空の場合は、/etc/passwdで定義したシェルが選択されます。
デフォルトでは、現在のユーザが前のユーザの環境を継承することから、前のユーザのディレクトリからsudo -sコマンドが実行されます。このコマンドは履歴にも記録されます。
永続的に昇格した特権でシェルを起動するには次のコマンドを入力します。
tux:~ >sudo -s[sudo] password for root:root:/home/tux #exittux:~ >
プロンプトが> から# に変わります。
これで、永続的に昇格した特権でシェルが起動しています。以降のすべてのコマンドは、パスワードの再入力を求められることなく実行できます。
4.3 sudo -iによるシェルの起動 #
sudo -iはsudo
-sコマンドラインオプションに似ていますが、起動するシェルは対話型ログインシェルです。sudo -sコマンドを使用すると、現在のユーザは前のユーザの環境を継承します。sudo -iコマンドを使用すると、これを防ぐことができます。この場合、ターゲットユーザはクリーンな環境を取得し、専用の$HOMEディレクトリで起動します。
sudo -iでコマンドを実行するには次のように入力します。
tux:~ >sudo -i[sudo] password for root:root:~ #exittux:~ >
永続的に昇格された特権でシェルが起動し、コマンドが履歴に記録されます。以降のすべてのコマンドは、パスワードの再入力を求められることなく実行できます。
5 sudoのベストプラクティス #
システムアクセスを制御し、ユーザの生産性を向上させるためのsudoのベストプラクティスをいくつか説明します。
sudo設定を徹底的にテストおよび監査します。真に効率的で安全な
sudo設定フレームワークを構築するには、定期的なテストと監査を定型業務として確立します。考えられる抜け穴を特定し、それに対処します。セキュリティよりも利便性を優先しないようにします。sudoのタイムアウトを制限するセキュリティ上の理由から、
root特権に無制限のアクセスを許可しないでください。代わりに、侵入者によるrootアカウントの悪用を防止するために適切なタイムアウトを設定します。詳細については、3項 「sudoのパスワードプロンプトのタイムアウト変更」を参照してください。visudoコマンドを使用する/usr/etc/sudoersファイルを安全に編集するにはvisudo -fコマンドを使用します。変更を保存する前に、このコマンドによってファイルの構文が確認されるからです。これは、システム中断の原因となりかねないエラーを修正するための予防的な手段です。基本的な構文チェックのほかに、visudo -cコマンドを実行して、sudo設定のフレームワーク全体が正しい順序で解析されていてエラーがないかどうかをチェックすることもできます。- 個人ではなくグループでユーザを管理する
sudo設定をできるだけ簡潔で管理しやすい状態に保ちます。ユーザをグループに追加し、個人ではなくそのグループに特権を付与することによって、ユーザを管理します。これにより、設定全体でユーザを探すことなく、グループ設定を変更するだけでユーザの追加や削除ができます。%admingrpグループに属するすべてのユーザがすべてのコマンドを実行できるようにするルールの例を以下に示します。%admingrp ALL = (ALL) ALL
- バイナリを実行できるパスを制限する
secure_pathディレクティブを使用して、ユーザがコマンドを実行できる領域を制限します。次の例は、SUSE Linux Enterprise Server for SAP applicationsにデフォルトで用意されている設定です。Defaults secure_path="/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin"
sudoログ記録の透過性を維持するsudoでは、ログのエントリを見失いやすい標準ログファイルにログが記録されます。設定に次のルールを追加して専用のsudoログファイルを指定します。Defaults logfile=/var/log/sudo.log
6 トラブルシューティング #
sudo設定の問題をデバッグおよびトラブルシューティングする方法について説明します。
6.1 /etc/sudoers.d/にあるカスタム設定の無視 #
/etc/sudoersの#includedirディレクティブでは、ファイル名の末尾が~文字であるファイルとファイル名に.文字が使用されているファイルが無視されます。これは、パッケージマネージャに用意されている設定ファイル(ファイル名に.が使用されいるファイル)と、エディタの一時ファイルやバックアップファイル(ファイル名の末尾が~であるファイル)に伴う問題を回避するための措置です。カスタム設定ファイルのファイル名にこのような文字を使用していないこと、ファイル名がこのような文字で終わっていないことを確認します。このような文字を使用しているファイル名、末尾がこのような文字であるファイル名は変更します。
6.2 カスタムディレクティブの競合 #
設定ファイルを読み取る順序によって、sudo設定ディレクティブが適用されるタイミングが決まります。/etc/sudoers.d/にあるファイルに記述したディレクティブは、/etc/sudoersにある同じディレクティブより優先されます。/etc/sudoers.d/に記述したカスタムディレクティブが機能しない場合は、visudo -cを使用してファイルの読み取り順序を確認します。必要に応じて、この順序を調整します。
6.3 破損したsudo設定によるロックアウト #
誤ってシステムのsudo設定を破損してしまい、sudoからロックアウトされた場合は、su -とrootパスワードを使用してルートシェルを起動します。visudo -cを実行してエラーがないかどうかをチェックし、visudoを使用してエラーを修正します。
7 sudo設定のリファレンス #
このセクションでは、デフォルトおよびカスタムの両方のsudo設定を理解および管理するのに役立つ基本的なsudo設定リファレンスを提供します。
7.1 sudoers設定の構文 #
sudoersの設定ファイルには、2種類のオプション(文字列とフラグ)があります。文字列には任意の値を指定できますが、フラグはONかOFFのいずれかです。sudoersの設定ファイルで最も重要な構文構造は次のとおりです。
# Everything on a line after # is ignored1 Defaults !insults # Disable the insults flag2 Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep3 tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl4
例外が2つあります。 | |
目的のフラグをONに設定するには | |
| |
ユーザ |
-
env_reset 設定すると、
sudoはTERM、PATH、HOME、MAIL、SHELL、LOGNAME、USER、USERNAME、およびSUDO_*で最小限の環境を構築します。また、env_keepに列挙されている変数は、呼び出し元の環境からインポートされます。デフォルトはONです。Defaults env_reset # Turn env_reset flag ON
-
env_keep env_resetフラグがONの場合に保持する環境変数の列挙。# Set env_keep to contain EDITOR and PROMPT Defaults env_keep = "EDITOR PROMPT" Defaults env_keep += "JRE_HOME" # Add JRE_HOME Defaults env_keep -= "JRE_HOME" # Remove JRE_HOME
-
env_delete env_resetフラグがOFFの場合に削除する環境変数の列挙。# Set env_delete to contain EDITOR and PROMPT Defaults env_delete = "EDITOR PROMPT" Defaults env_delete += "JRE_HOME" # Add JRE_HOME Defaults env_delete -= "JRE_HOME" # Remove JRE_HOME
7.2 基本的なsudoersルール #
各ルールは、次のスキームに従います([]はオプション部分を示しています)。
#Who Where As whom Tag What User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List
-
User_List 1つ以上の(コンマで区切られた)識別子。ユーザ名、
%GROUPNAME形式のグループ、または#UID形式のユーザIDを指定します。否定は!プレフィクスで指定できます。-
Host_List 1つ以上の(コンマで区切られた)識別子。(完全修飾された)ホスト名またはIPアドレスのいずれかを指定します。否定は
!プレフィクスで指定できます。通常、Host_ListにはALLを選択します。-
NOPASSWD:|PASSWD: NOPASSWD:の後に記述した、Cmd_Listと一致するコマンドを実行する場合は、パスワードが要求されません。PASSWD:はデフォルトです。PASSWD:とNOPASSWD:の両方が同じ行に存在する場合にのみ指定する必要があります。tux ALL = PASSWD: /usr/bin/foo, NOPASSWD: /usr/bin/bar
-
Cmnd_List 1つまたは複数の(コンマで区切られた)指定子。実行可能ファイルへのパスの後に、オプションで使用可能な引数を指定します。
/usr/bin/foo # Anything allowed /usr/bin/foo bar # Only "/usr/bin/foo bar" allowed /usr/bin/foo "" # No arguments allowed
ALLは、User_List、Host_List、およびCmnd_Listとして使用できます。
7.3 エイリアスを使用したsudoersの簡潔化 #
エイリアスを取り入れて項目をグループ化すると、管理者は繰り返しの多い一連のルールを個別に維持する必要がなくなります。これらの構文はルールの構文と同じです。次のタイプのエイリアスがサポートされています。
-
User_Alias ユーザ名のリスト
-
Runas_Alias UID別のユーザのグループ
-
Host_Alias ホスト名のリスト
-
Cmnd_Alias コマンドとディレクトリ、およびエイリアスのリスト
エイリアスは、ユーザ、グループ、コマンド、およびホストの名前付きリストと考えてください。次にエイリアスの機能例を挙げます。
Host_Alias WEBSERVERS = www1, www2, www31 User_Alias ADMINS = tux, wilber, suzanne2 Cmnd_Alias REBOOT = /sbin/halt, /sbin/reboot, /sbin/poweroff3 ADMINS WEBSERVERS = REBOOT4
3台のサーバを1つのHost_Alias | |
前記のグループ化したホストと同様に、グループユーザやユーザのグループ( | |
同じコンテキストで使用するコマンドのグループを指定しています。 | |
|
要約すると、エイリアスは、管理者がsudoersを管理しやすく簡潔な状態(したがって安全な状態)に保つのに役立ちます。たとえば、ユーザの1人が退職した場合、この特定のユーザを含むルールをすべて検索するのではなく、User_Aliasステートメントと、そのユーザが属していたシステムグループからこの人物の名前を一度削除するだけです。
8 法的事項 #
Copyright© 2006–2025 SUSE LLC and contributors. All rights reserved.
この文書は、GNU Free Documentation Licenseのバージョン1.2または(オプションとして)バージョン1.3の条項に従って、複製、頒布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2のコピーは、「GNU Free Documentation License」セクションに含まれています。
SUSEの商標については、https://www.suse.com/company/legal/を参照してください。その他の第三者のすべての商標は、各社の所有に帰属します。商標記号(®、™など)は、SUSEおよび関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。
本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは正確性を完全に保証するものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。