SUDO.CONF

名前

説明

[訳注]:

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" ロケールで行われる。  

プラグインの設定

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 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 である。

その他の設定

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 でしか使用できない。

デバッグ・フラグ

デバッグ行の構成は、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

関連項目

履歴

作者

Todd C. Miller

sudo の開発に貢献してくださった方々の詳細なリストについては、 配布物中の CONTRIBUTORS ファイルをご覧になっていただきたい。 (https://www.sudo.ws/contributors.html)  

バグ

サポート

免責

Index

名前

説明

プラグインの設定

パスの設定

その他の設定

デバッグ・フラグ

ファイル

用例

関連項目

履歴

作者

バグ

サポート

免責