プラグインの設定¶

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

group_source

sudo は、起動したユーザが所属するグループのリストをポリシー・プラグインと 入出力プラグインに引き渡す。ほとんどのシステムでは、 一人のユーザが同時に所属することのできるグループの数に上限がある (NFS との互換性のために、たいていは 16)。システムに getconf(1) ユーティリティ・コマンドが存在するなら、

Set group_source static

max_groups

グループ・データベースから取得するユーザの所属グループの最大数。 1 未満の値は無視されることになる。この設定が使用されるのは、 グループ・データベースに直接問い合わせるときだけである。 グループのリストを入れることになっている配列が十分な大きさを持っていない場合にも、 それを検出できないシステムが存在する。 この設定は、そうしたシステムで使用することを目的にしている。 デフォルトでは、sudo はシステムが規定しているグループの最大数の (上記参照) 4 倍の配列を割り当て、グループ・データベースへの問い合わせが失敗した場合は、 その数をさらに倍にして再実行することになっている。しかしながら、 システムの中には、配列に納まる数のグループを返すだけで、 スペースが不足していてもエラーを知らせないものがあるのだ。

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

probe_interfaces

デフォルトでは、sudo はシステムのネットワーク・インターフェースを調べて、 有効になっている各インターフェースの IP アドレスをポリシー・プラグインに伝える。 そのため、プラグインは、DNS に問い合わせるまでもなく、 ルールを適用するかどうかを IP アドレスに基づいて決めることができるわけだ。 Linux のシステムで多数のバーチャル・インターフェースを使用している場合は、 この作業に無視できない時間がかかるかもしれない。 IP アドレスに基づいたルールのマッチングが必要ないならば、 ネットワーク・インターフェースの検査を次のようにして無効にすることができる。

Set probe_interfaces false

デバッグ・フラグ¶

バージョン 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) プラグインがサポートしているサブシステムには、これ以外のものもある。