名前

sudo.conf - sudo フロントエンドの設定

説明

sudo.conf ファイルは、sudo フロントエンドの設定に使用される。 セキュリティポリシー・プラグイン、入出力ロギング・プラグイン、 デバッグ・フラグの指定をはじめ、 プラグインが何かにはかかわりののない (プログラムやライブラリの) パス名や、 sudo フロントエンドのその他の設定も、ここで指定することができる。
[訳注]:
sudoers ファイルが、誰が何を実行できるかなどの sudoers セキュリティポリシーの設定に使用されるのに対して、 sudo.conf ファイルは、 sudo コマンドが使用するセキュリティポリシー・プラグインを特定したり、 どんなデバッグ情報を記録するかを指定したりするなど、 sudo フロントエンド、 すなわち sudo コマンドそのものの動作の設定に使用される。
sudo.conf では、次の命令 (directive) が使用できる。各命令については、 以下で詳しく説明する。
Plugin
セキュリティポリシー・プラグインや入出力ロギング・プラグインを指定する
Path
プラグインが何かにはかかわりのない (プログラムやライブラリの) パス
Set
disable_coredump や group_source のようなフロントエンドの設定
Debug
sudo, sudoreplay, visudo、及び sudoers プラグインのデバッグに使用するデバッグ・フラグ
パウンド記号 ('#') は、コメントであることを示すために使用される。 コメントを示す記号とそれに続くテキストは、行末に至るまで無視される。
長い行は、行末にバックスラッシュ ('\') を置くことで、継続することができる。 行頭にあるホワイト・スペースは、行の継続を示す記号が使われている場合でも、 行頭から取り除かれることに注意していただきたい。
コメント行以外でも、Plugin, Path, Debug, Set で始まっていない行は、無視される。 エラーや警告メッセージを出すこともない。
sudo.conf ファイルの解析は、常に "C" ロケールで行われる。

プラグインの設定

sudo はセキュリティポリシーと入出力のロギングについて、プラグイン方式をサポートしている。 従って、サードパーティは、 sudo のフロントエンドとシームレスに協働するポリシー・プラグインや、 入出力ロギング・プラグインを独自に開発して、配布することができる。 プラグインは、 sudo.conf の記述に基づいて、動的にロードされる。
Plugin 行は、キーワード Plugin に始まり、 symbol_name と path が続く。 path は、プラグインを含む動的共有オブジェクトへのパスである。 symbol_name は、プラグインに含まれる policy_plugin 構造体や io_plugin 構造体のシンボル名である。 path は絶対パスでも相対パスでもよい。 相対パスの場合は、Path 命令の plugin_dir で指定したディレクトリを基点とする相対パスであり、 デフォルトの基点は /usr/local/libexec/sudo である。すなわち、 
 


Plugin sudoers_policy sudoers.so

は、次のものと同じだということだ。 
 


Plugin sudoers_policy /usr/local/libexec/sudo/sudoers.so

プラグインが動的な共有オブジェクトとしてインストールされているのではなく、 sudo のバイナリに静的に組み込まれている場合は、 path にディレクトリまで指定してはいけない。 ファイルシステム中に実際に存在するわけではないからだ。 すなわち、こんなふうに指定する。 
 


Plugin sudoers_policy sudoers.so

sudo 1.8.5 以降では、path の後ろにパラメータを付けると、それは、 プラグインの open 関数に引き数として渡されるようになっている。たとえば、 コンパイル時に指定した sudoers ファイルのデフォルトのモードを変更するには、 次のようにする。 
 


Plugin sudoers_policy sudoers.so sudoers_mode=0440

使用できる引き数のリストについては、sudoers(5) のマニュアルをご覧いただきたい。
一つの動的な共有オブジェクトが、 それぞれ違ったシンボル名を持つ複数のプラグインを含んでいても構わない。 共有オブジェクト・ファイルは、uid 0 の所有でなければならず、 また、所有者のみ書き込み可能でなければならない。 同時に複数のポリシーがあると、曖昧さが生じるので、 ポリシー・プラグインは一つしか指定できない。 この制限は 入出力プラグインには当てはまらない。
sudo.conf ファイルが存在しない場合や、存在しても Plugin 行を含まない場合は、 デフォルトのセキュリティポリシーとして sudoers プラグインが使用されることになる。 入出力ロギングにも (ポリシーによって有効になっていれば)、 sudoers プラグインが使用される。これは次の記述と同じことである。 
 


Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so

sudo プラグインの仕組みについてもっと詳しい情報が必要なら、 sudo_plugin(5) のマニュアルをご覧になっていただきたい。

パスの設定

Path 行は、キーワード Path に始まり、設定するパスの名称とその値が続く。 たとえば、次のようにだ。 
 


Path noexec /usr/local/libexec/sudo/sudo_noexec.so
Path askpass /usr/X11R6/bin/ssh-askpass

パス名が (訳注: パスの名称ではなく、パスの値が) 指定されていない場合は、 その設定に依存する機能を無効化することになる。 パス設定の無効化をサポートしているのは、バージョン 1.8.16 以上の sudo だけである。
以下に挙げるような、 プラグインが何かにはかかわりのない (プログラムやライブラリの) パスを /etc/sudo.conf で設定することができる。
askpass
端末が利用できないときに、ユーザのパスワードを読み込むのに使用するヘルパー・プログラムの絶対パス。 たとえば、 sudo がグラフィカルな (つまり、テキストベースではない) アプリケーションから実行される場合がこれに当たる。 askpass で指定されたプログラムは、自分に渡された引き数をプロンプトとして表示し、 ユーザのパスワードを標準出力に書き出すべきである。 askpass の値は、 環境変数 SUDO_ASKPASS によって上書きすることができる。
noexec
ライブラリ関数 execl(), execle(), execlp(), exect(), execv(), execve(), execvP(), execvp(), execvpe(), fexecve(), popen(), posix_spawn(), posix_spawnp(), system() のダミー版 (単にエラーを返すだけの関数) が入っている共有ライブラリの絶対パス。 これは LD_PRELOAD やそれに相当するものをサポートするシステムで noexec 機能を実現するために使用される。デフォルトの値は /usr/local/libexec/sudo/sudo_noexec.so である。
plugin_dir
絶対パスで指定されていないプラグインを捜すときに使用されるデフォルトのディレクトリ。 デフォルトの値は /usr/local/libexec/sudo である
sesh
sesh バイナリの絶対パス。この設定は、 sudo が SELinux サポートを有効にしてビルドされたときにのみ、使用される。 デフォルトの値は /usr/local/libexec/sudo/sesh である。

その他の設定

sudo.conf ファイルでは、以下に挙げるフロントエンドの設定も行うことができる。
disable_coredump
デフォルトでは、セキュリティ上問題になるかもしれない情報を漏洩しないように、 sudo 自体のコアダンプは無効になっている。 sudo そのもののクラッシュをデバッグするためにコアダンプを有効に戻したいならば、 次のように、 sudo.conf で "disable_coredump" を false にすればよい。 
 

    
Set disable_coredump false

 
最近のオペレーティング・システムでは、どのシステムでも、 sudo のような setuid プロセスのコアダンプについて各種の制限を設けているので、 このオプションを有効にしても、セキュリティが弱体化することはない。 sudo のコアファイルを実際に得るためには、 たぶん setuid プロセスに対するコアダンプを有効にする必要があるだろう。 BSD や Linux のシステムでは、それは sysctl コマンドで行われる。 Solaris では、coreadm コマンドがコアダンプの動作設定に使用される。
 
この設定は、バージョン 1.8.4 以降の sudo でしか使用できない。
group_source
sudo は、起動したユーザが所属するグループのリストをポリシー・プラグインと 入出力プラグインに引き渡す。ほとんどのシステムでは、 一人のユーザが同時に所属することのできるグループの数に上限がある (NFS との互換性のために、たいていは 16)。システムに getconf(1) ユーティリティ・コマンドが存在するなら、
getconf NGROUPS_MAX
を実行すれば、グループの最大数がわかる。
 
しかしながら、ユーザが上限を越える数のグループのメンバーになることも可能である -- 上限を越えた分は、そのユーザについてカーネルが返すグループのリストに含まれないだけのことだ。 バージョン 1.8.7 以降の sudo では、 ユーザについてカーネルが返すグループのリストが所属グループの最大数に達しているときは、 sudo はグループ・データベースを直接調べて、グループのリストを決定するようになっている。 そうすることによって、ユーザが所属グループの最大数よりも多くのグループのメンバーであるときも、 セキュリティポリシーがグループ名によるマッチングを行うことができるようにしているのである。
 
group_source の設定によって、管理者がこのデフォルトの動作を変更することができる。 group_source に対して使用できる値は以下のものである。
static
カーネルが返す static なグループ・リストを使用する。 グループ・リストをこの方法で取得するのは迅速だが、上で述べた上限を課されることになる。 この方法が "static (静的)" だというのは、ユーザがログインした後で行った、 グループ・データベースに対する変更を反映しないからである。 これは、 sudo 1.8.7 以前のデフォルトの動作だった。
dynamic
常にグループ・データベースに問い合わせる。この方法が "dynamic (動的)" だというのは、ユーザがログインした後でグループ・データベースに行った変更が、 グループのリストに反映するからである。システムによっては、 グループ・データベースにユーザが所属するすべてのグループを問い合わせると、 非常に時間がかかることがある。 ネットワーク・ベースのグループ・データベースに問い合わせる場合などがそうだ。 もっとも、たいていのオペレーティング・システムは、 そうした問い合わせを効率的に行う方法を用意している。現在のところ、 sudo は、AIX, BSD, HP-UX, Linux, Solaris で効率的なグループの問い合わせをサポートしている。
adaptive
カーネルが返す static なグループのリストが、所属グループの最大数に達しているときにのみ、 グループ・データベースに問い合わせる。これが sudo 1.8.7 以降のデフォルトの動作である。
たとえば、 sudo が、ユーザについてカーネルが返す static なグループのリストのみを使うようにしたかったら、以下のように指定する。 
 


Set group_source static

 
この設定は、バージョン 1.8.7 以降の sudo でしか使用できない。
max_groups
グループ・データベースから取得するユーザの所属グループの最大数。 1 未満の値は無視されることになる。この設定が使用されるのは、 グループ・データベースに直接問い合わせるときだけである。 グループのリストを入れることになっている配列が十分な大きさを持っていない場合にも、 それを検出できないシステムが存在する。 この設定は、そうしたシステムで使用することを目的にしている。 デフォルトでは、 sudo はシステムが規定しているグループの最大数の (上記参照) 4 倍の配列を割り当て、グループ・データベースへの問い合わせが失敗した場合は、 その数をさらに倍にして再実行することになっている。しかしながら、 システムの中には、配列に納まる数のグループを返すだけで、 スペースが不足していてもエラーを知らせないものがあるのだ。 この設定は、バージョン 1.8.7 以降の sudo でしか使用できない。
probe_interfaces
デフォルトでは、sudo はシステムのネットワーク・インターフェースを調べて、 有効になっている各インターフェースの IP アドレスをポリシー・プラグインに伝える。 そのため、プラグインは、DNS に問い合わせるまでもなく、 ルールを適用するかどうかを IP アドレスに基づいて決めることができるわけだ。 Linux のシステムで多数のバーチャル・インターフェースを使用している場合は、 この作業に無視できない時間がかかるかもしれない。 IP アドレスに基づいたルールのマッチングが必要ないならば、 ネットワーク・インターフェースの検査を次のようにして無効にすることができる。 
 

    
Set probe_interfaces false

 
この設定は、バージョン 1.8.10 以降の sudo でしか使用できない。

デバッグ・フラグ

バージョン 1.8.4 以上の sudo は、デバッグのための柔軟な枠組みに対応しており、 問題が生じたときに、 sudo の内部で何が起きているかを突き止めるために、 それを利用することができる。
デバッグ行の構成は、Debug というキーワードに始まり、 デバッグ対象 ( sudo, visudo, sudoreplay, sudoers) のプログラム名、またはプラグイン名と、デバッグファイル名がそれに続き、 最後にコンマで区切ったデバッグ・フラグのリストが来るという形になっている。 デバッグ・フラグのシンタクスは、 sudo と sudoers プラグインでは、 subsystem@ priority という書式を用いるが、コンマ (',') を含まないかぎり、別の書式を使用するプラグインがあっても構わない。
一例を挙げよう。 
 


Debug sudo /var/log/sudo_debug all@warn,plugin@info

上記のように指定すると、 warn レベル以上のすべてのデバッグ情報に加えて、 プラグイン・サブシステムについては、 info レベル以上の情報もログに記録することになる。
sudo 1.8.12 以来、一つのプログラムについて複数の Debug 行が指定できるようになっている。 sudo のそれ以前のバージョンでは、1 プログラムにつき 1 行の Debug 行しかサポートしていなかった。 sudo 1.8.12 からは、 プラグイン独自の Debug 行もサポートされるようになり、そうした行のマッチングは、 ロードされているプラグインのベースネーム (たとえば、sudoers.so)、 またはプラグインの絶対パス名によって行われる (訳注: 言い換えれば、 プラグイン独自の Debug 行では、プログラム名/プラグイン名の位置に Plugin 行における path の部分を指定するということだろう)。以前のバージョンでは、 sudoers プラグインは、sudo フロントエンドと同じ Debug 行を共有しており、別の設定をすることができなかった。
次の priority (重大度) が使用できる。深刻なものから挙げると、 crit, err, warn, notice, diag, info, trace, debug である。 ある priority を指定すると、それよりも深刻なすべての priority も指定したことになる。 たとえば、 notice という priority を指定すれば、 notice レベル以上のデバッグ情報がログに記録されるわけである。
trace と debug の priority では、ファンクション・コールのトレースも行われ、 関数に入ったときと関数から戻ったときのログも記録される。たとえば、 次のトレースは、src/sudo.c にある get_user_groups() 関数に対するものである。 
 


sudo[123] -> get_user_groups @ src/sudo.c:385
sudo[123] <- get_user_groups @ src/sudo.c:429 := groups=10,0,5

関数に入ったときは、右矢印 '->' で示され、プログラム名、プロセス ID、 関数名、ソースファイルと行番号が記録される。 関数から戻ったときは、左矢印 '<-' で示され、同じ情報に加えて、 返り値が記録される。上記の場合、返り値は文字列である。
sudo フロントエンドでは、以下のサブシステムが使用できる。
all
すべてのサブシステムにマッチする
args
コマンドライン引き数の処理
conv
ユーザとのやりとり
edit
sudoedit
event
event サブシステム
exec
コマンドの実行
main
sudo のメイン関数
netif
ネットワーク・インターフェースの取扱い
pcomm
プラグインとのやりとり
plugin
プラグインの設定
pty
擬似 tty 関連コード
selinux
SELInux 特有の取扱い
util
ユーティリティ関数群
utmp
utmp の取扱い
sudoers(5) プラグインがサポートしているサブシステムには、これ以外のものもある。

ファイル

/etc/sudo.conf
sudo フロントエンドの設定ファイル

用例

#
# Default /etc/sudo.conf file
#
# Format:
#   Plugin plugin_name plugin_path plugin_options ...
#   Path askpass /path/to/askpass
#   Path noexec /path/to/sudo_noexec.so
#   Debug sudo /var/log/sudo_debug all@warn
#   Set disable_coredump true
#
# plugin_path が絶対パスでない場合は、/usr/local/libexec/sudo からの
#   相対パスである。
# plugin_name は、プラグイン中の、プラグインのインターフェース構造を
#   含むグローバル・シンボルと同じものである。
# plugin_options を指定するかしないかは、任意である。
#
# Plugin 行が存在しない場合、デフォルトの sudoers プラグインが
# 使用される。
Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so


#
# Sudo askpass:
#
# askpass ヘルパー・プログラムを指定すると、sudo の "-A" オプションで
# 使用できるように、グラフィカルなパスワード・プロンプトを用意する
# ことができる。sudo は、自前の askpass プログラムを配布していないが、
# たとえば、OpenSSH の askpass を使用することが可能だ。
#
# OpenSSH askpass を使用する。
#Path askpass /usr/X11R6/bin/ssh-askpass
#
# Gnome の OpenSSH askpass を使用する。
#Path askpass /usr/libexec/openssh/gnome-ssh-askpass


#
# Sudo noexec:
#
# ライブラリ関数 execv(), execve(), fexecve() のダミー版 (単にエラー
# を返すだけの関数) が入っている共有ライブラリのパス。この指定は、
# <LD_PRELOAD> やそれに相当するものをサポートしているシステムで
# "noexec" 機能を実現するために使用される。たいていの場合、
# コンパイル時に組み込まれた値で十分であり、変更するのは、
# sudo_noexec.so ファイルをリネームしたり、移動したりしたときのみに
# するべきである。
#
#Path noexec /usr/local/libexec/sudo/sudo_noexec.so


#
# Core dumps:
#
# sudo はデフォルトでは、自己を実行中のコアダンプを抑止している
# (指定されたコマンドを実行するときに、コアダンプを有効にし直す
# のだ)。sudo 自体の問題をデバッグするために、コアダンプを有効に
# 戻したいならば、"disable_coredump" を false にすればよい。
#
#Set disable_coredump false


#
# User groups:
#
# sudo は、ユーザが属するグループのリストをポリシー・プラグインに
# 引き渡す。ユーザの所属グループが、所属グループの最大数 (たいていは
# 16) に達している場合は、sudo は、そのユーザが所属するグループを
# すべて取得するため、直接グループ・データベースに問い合わせを行う。
#
# システムによっては、この動作は負担がかかることがあるので、設定に
# よって変更できるようになっている。"group_source" で設定できる
# 値には、三つのものがある。
#   static   - ユーザが属するグループのリストにカーネルが返したものを
#              使用する。
#   dynamic  - グループのリストを知るために、グループ・データベースに
#              問い合わせる。
#   adaptive - ユーザの所属グループが、所属グループの最大数より少ない
#              ときは、カーネルの返すリストを使う。さもなければ、
#              グループ・データベースに問い合わせる。
#
#Set group_source static

関連項目

sudoers(5), sudo(8), sudo_plugin(5)

履歴

sudo の簡単な履歴については、 sudo の配布に含まれている HISTORY ファイルをご覧いただきたい。 (https://www.sudo.ws/history.html)

作者

多数の人々が長年に渡って sudo の開発に携わってきた。 当バージョンは主として次の者が書いたコードからできている。
 
Todd C. Miller
sudo の開発に貢献してくださった方々の詳細なリストについては、 配布物中の CONTRIBUTORS ファイルをご覧になっていただきたい。 (https://www.sudo.ws/contributors.html)

バグ

sudo にバグを発見したと思ったら、https://www.sudo.ws/ にアクセスして、バグレポートを提出していただきたい。

サポート

ある程度の無料サポートが sudo-users メーリングリストを通して利用できる。 購読やアーカイブの検索には、次の URL を御覧になるとよい。 https://www.sudo.ws/mailman/listinfo/sudo-users

免責

sudo は「現状のまま」提供される。 明示的な、あるいは黙示的ないかなる保証も、 商品性や特定目的への適合性についての黙示的な保証を含め、 またそれのみに止まらず、これを否認する。詳細な全文については、 sudo と一緒に配布されている LICENSE ファイルや、 次の Web ページをご覧いただきたい。 https://www.sudo.ws/license.html

Recommended readings

Pages related to sudo.conf you should read also:
getconf(1) sudo(8) sudo_plugin(5) sudoers(5)

Questions & Answers

Helpful answers and articles about sudo.conf you may found on these sites:
Stack Overflow Server Fault Super User Unix & Linux Ask Ubuntu Network Engineering DevOps Raspberry Pi Webmasters Google Search