Provided by: manpages-ja_0.5.0.0.20180315+dfsg-1_all 
名前
sudoers.ldap - LDAP を使用した sudoers ポリシーの設定
説明
sudoers セキュリティポリシーは sudoers ファイルによって設定するのが標準だが、 LDAP を通し
て設定することもできる。この方法は、大規模な分散環境で sudoers セキュリティポリシーの設定
を同期させたい場合に、 とりわけ便利かもしれない。
sudoers セキュリティポリシーの設定に LDAP を使用すると、有利な点がいくつかある。
• sudo はもはや sudoers セキュリティポリシーの設定をまるまる全部読み込む必要がない。
LDAP を使用する場合は、sudo の実行ごとに、たった二、三回 LDAP に問い合わせを行うだけで
すむ。 そのため、LDAP 環境は実行速度が非常に早く、たいへん使い勝手がよい。
• sudoers セキュリティポリシーの設定にタイプミスがあっても、 もうそのために sudo が終了
してしまうことがない。 LDAP のデータは、sudo 用のスキーマに従っていなければ、 サーバー
にロードできない。結果として、 正しいシンタクスが保証されることになる。 ユーザ名やホス
ト名をタイプミスすることなら相変わらずあるだろうが、 そのために sudo が動かなくなるこ
とはない。
• エントリごとにオプションを指定して、 グローバルなデフォルト・オプションを上書きするこ
とができる。 /etc/sudoers はグローバルなデフォルト・オプションと、ユーザ、ホスト、 コ
マンド、変身対象に結びついた限定されたオプションしかサポートしていない。 ま
た、/etc/sudoers の書式は複雑で、ユーザには理解しにくいかもしれない。 オプションをエン
トリ内で直接指定する方が、ずっと自然である。
• visudo プログラムはもう必要がない。visudo の役割は、 /etc/sudoers ファイルのロッキング
とシンタクス・チェックである。 LDAP のデータ更新はアトミック操作なので (訳注: それ
故、データは更新されていないか、 すでに更新されたかのどちらかであって、中間状態がない
ので)、 ロッキングはもはや必要ではない。シンタクスは、 データが LDAP にインサートされ
るときチェックされるから、 シンタクス・チェック用の特別なツールも不要になっている。
LDAP による設定と sudoers ファイルによる設定との、もう一つの大きな違いは、 LDAP では sudo
専用のエイリアスがサポートされていないことである。
たいていの場合、sudo 専用のエイリアスは実のところ必要がない。 User_Aliases や
Runas_Aliases の代わりに、 Unix のグループ、non-Unix グループ (group_plugin を介して)、
ユーザのネットグループが使用できる。 また、Host_Aliases の代わりには、ホストのネットグルー
プが使える。 LDAP には グループやネットグループも格納できるので、 sudo 専用のエイリアスが
どうしても必要というわけではないのだ。
Cmnd_Aliases もまったく必要がない。 一つの sudoRole エントリに複数のユーザを登録できるから
だ。 複数のユーザが参照する Cmnd_Alias を定義する代わりに、 複数のコマンドを含む sudoRole
エントリを一つ作成して、 そこに複数のユーザを割り当てればよい。
[訳注]: 原文の著者は、sudoers セキュリティポリシーの設定の単位となる objectClass 属性が
sudoRole の LDAP エントリのうち、 /etc/sudoers の各ユーザ設定に相当するものを「a
sudoRole」と呼んでいる。 「sudoRole エントリ」という訳語を当てた。
LDAP の SUDOers コンテナ
LDAP では、sudoers セキュリティポリシーの設定は ou=SUDOers コンテナの下に配置されている。
[訳注]: ここで言うコンテナ (容器、入れもの) とは、データを格納するためではなく、 データを
含む下位のエントリをまとめておくために存在する上位エントリのことである。 たとえ
ば、OpenLDAP 用の ou=SUDOers コンテナなら、 その設定ファイルの記述はこんなふうにな
る (sudo 同梱の README.LDAP から引用)。
dn: ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: SUDOers
sudo はまず最初に SUDOers コンテナ配下に cn=defaults のエントリを捜す。 見つかった場合
は、複数回指定可能な sudoOption 属性が、/etc/sudoers のグローバルな Defaults 行と同じやり
方で解析される。以下の例では、 環境変数 SSH_AUTH_SOCK がすべてのユーザの環境に保存されるこ
とになる。
dn: cn=defaults,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here
sudoOption: env_keep+=SSH_AUTH_SOCK
LDAP において /etc/sudoers の個々の「ユーザ設定」に相当するのは、 sudoRole エントリであ
る。それは以下の属性からなっている。
sudoUser
次のうちのいづれか。ユーザ名、ユーザ ID (接頭辞 '#' が付く)、 Unix グループ名または
グループ ID (それぞれ接頭辞 '%' と '%#' が付く)、ユーザのネットグループ (接頭辞 '+'
が付く)、 non-Unix グループ名またはグループ ID (それぞれ接頭辞 '%:' と '%:#' が付
く)。 なお、ユーザのネットグループについては、 ネットグループの成員中のユーザとドメ
インの要素のみを使って、マッチングが行われる。 ホストの要素はマッチングに使用されな
い。 non-Unix グループが使用できるのは、グローバルな defaults sudoRole オブジェクト
で適切な group_plugin が指定されているときだけである。
sudoHost
次のうちのいづれか。ホスト名、IP アドレス、ネットワークアドレス、 ホストのネットグ
ループ (接頭辞 '+' が付く)。 ALL という特別な値はいかなるホストにもマッチする。 な
お、ホストのネットグループについては、 ネットグループの成員中のホスト (完全修飾名と
そうでないもののどちらでも) とドメインの要素のみを使って、マッチングが行われる。
ユーザの要素はマッチングに使用されない。
sudoCommand
絶対パスで指定した Unix のコマンド名。コマンドライン引数を付けてもよく、 glob 文字
(ワイルドカードとも言う) を含んでいてもよい。 コマンドに感嘆符 '!' を接頭辞として付
けると、 ユーザにそのコマンドの実行を禁じることになる。
コマンド名として組み込みコマンドの "sudoedit" を使用すれば、 ユーザが sudo を -e オ
プション付きで (あるいは、sudoedit の名前で) 実行するのを許可することになる。普通の
コマンドの場合と同じように、 コマンドライン引数まで指定してもよい。"sudoedit" は
sudo 本体に組み込まれたコマンドなので、これをコマンド名に指定するときは、 頭にパスを
つけてはいけないことに注意していただきたい。
ALL という特別な値は、いかなるコマンドにもマッチする。
コマンド名の前に SHA-2 ダイジェストが付いていると、実行が許可されるのは、 ダイジェス
トがマッチしたときだけになる。これは、sudo を実行するユーザが、 対象となるコマンドや
その親ディレクトリに書き込み権限を持っているような場合に、 役に立つだろう。ダイジェ
ストのフォーマットとしては、sha224, sha256, sha384, sha512 がサポートされている。ダ
イジェスト名の後ろにはコロン (':') を置いて、その後に実際のダイジェストを続けなけれ
ばならない。 ダイジェストは、16 進数でも base64 形式でもよい。 たとえば、sudoCommand
に対して以下の値を指定すると、
sha224:0GomF8mNN3wlDt1HD9XldjJ3SNgpFdbjO1+NsQ /bin/ls
ユーザが /bin/ls を実行できるのは、/bin/ls の sha224 ダイジェストが指定した値とマッ
チしたときだけになる。 コマンドのダイジェストをサポートしているのは、バージョン
1.8.7 以上だけである。
sudoOption
働きは、前述のグローバルオプションと同じだが、それが属している sudoRole エントリに対
してのみ効果がある。
sudoRunAsUser
変身対象となるユーザ名か uid (接頭辞 '#' が付く) を指定する。 変身対象ユーザをリスト
に含む Unix グループ名 (接頭辞 '%' が付く) や、 ユーザのネットグループ (接頭辞 '+'
が付く) も使える。 特別な値 ALL は、いかなるユーザにもマッチする。
属性 sudoRunAsUser は、バージョン 1.7.0 以上の sudo でなければ、 利用できない。それ
以前のバージョンの sudo では、 代わりに属性 sudoRunAs を使用している。
sudoRunAsGroup
変身対象となる Unix グループ名か gid (接頭辞 '#' が付く)。 特別な値 ALL はいかなるグ
ループにもマッチする。
属性 sudoRunAsGroup は、バージョン 1.7.0 以上の sudo でなければ、 利用できない。
sudoNotBefore
yyyymmddHHMMSSZ 形式のタイムスタンプ。 この属性を含む sudoRole エントリがいつから有
効になるかという、 スタート日時を指定するのに使用する。 複数の sudoNotBefore が存在
する場合は、一番早い日時が採用される。 タイムスタンプは協定世界時 (UTC) によるもので
なければならず、 ローカル・タイムゾーンによるものではないことに注意していただきた
い。 分や秒の部分は省略できるが、LDAP サーバによっては (RFC の規定に反して) 分や秒の
指定を必須にしていることもある。
属性 sudoNotBefore は、バージョン 1.7.5 以上の sudo でなければ、 利用できない。ま
た、/etc/ldap.conf の SUDOERS_TIMED オプションで明示的に有効にする必要がある。
sudoNotAfter
yyyymmddHHMMSSZ 形式のタイムスタンプ。 この属性を含む sudoRole エントリがもはや有効
ではなくなる、 失効日時を示している。複数の sudoNotAfter が存在する場合は、 一番最後
の日時が採用される。 タイムスタンプは協定世界時 (UTC) によるものでなければならず、
ローカル・タイムゾーンによるものではないことに注意していただきたい。 分や秒の部分は
省略できるが、LDAP サーバによっては (RFC の規定に反して) 分や秒の指定を必須にしてい
ることもある。
属性 sudoNotAfter は、バージョン 1.7.5 以上の sudo でなければ、 利用できない。ま
た、/etc/ldap.conf の SUDOERS_TIMED オプションで明示的に有効にする必要がある。
sudoOrder
LDAP から取り出される sudoRole エントリには、固有の順番というものがない。 そこで、整
数の値を取る sudoOrder 属性を使用して (浮動小数点値をサポートする LDAP サーバで
は、浮動小数点値も使える)、マッチするエントリの順番付けを行う。 そうすることで、LDAP
による sudoers 設定のエントリが、 エントリの順番が結果に影響を及ぼす sudoers ファイ
ルの動作を、 より忠実に真似られるようになるわけだ。 sudoOrder 属性を使用すると、複数
のエントリがマッチする場合には、 一番大きな sudoOrder 属性を持つエントリが選ばれるこ
とになる。この動作は、 sudoers ファイルの「最後にマッチしたものが選ばれる」動作に相
当するわけである。 sudoOrder 属性が指定されていない場合は、値が 0 であると見なされ
る。
属性 sudoOrder は、バージョン 1.7.5 以上の sudo でなければ、 利用できない。
上記の各属性は単一の値を持つべきだが、同じタイプの属性が複数回現れても構わない。 sudoRole
エントリは、sudoUser、sudoHost、sudoCommand を、 少なくともそれぞれ一個は含んでいなければ
ならない。
次の例では、wheel グループのユーザに sudo 経由でいかなるホストでも任意のコマンドの実行を許
可している。
dn: cn=%wheel,ou=SUDOers,dc=example,dc=com
objectClass: top
objectClass: sudoRole
cn: %wheel
sudoUser: %wheel
sudoHost: ALL
sudoCommand: ALL
LDAP を使って sudoers セキュリティポリシーの設定を照合するときの詳細
LDAP を使って、あるユーザに関する sudoers セキュリティポリシーを照合するとき、 LDAP の問い
合わせは sudo の実行ごとにたった二回か三回行われるだけである。 一回目の問い合わせは、グ
ローバル・オプションを解析するために行われる。 二回目の問い合わせは、sudo を実行するユーザ
のユーザ名や、 所属グループに対応するエントリを見つけるためだ (特別なタグ ALL が何にでも
マッチするのは、この場合も同様である)。 ユーザ名やグループに対応するエントリが得られなかっ
た場合は、 三回目の問い合わせが行われ、ユーザのネットグループや non-Unix グループを含んで
いるすべてのエントリーを取得して、 問題のユーザがそのどれかに属していないかをチェックす
る。
/etc/ldap.conf の設定オプション SUDOERS_TIMED を有功にして、 エントリの日時制限を使えるよ
うにしている場合は、 LDAP の問い合わせにサブフィルターによる選別が伴うことになる。 そのサ
ブフィルターが、日時制限が存在するエントリについては、 その制限を満たしているエントリのみ
に、情報の検索を限定するのである。
NETGROUP_BASE 設定オプションが使用されている場合は (下記の 「ldap.conf の設定」を参照)、
ユーザがどことどこのネットグループに所属しているかを調べるための問い合わせが、 sudoers セ
キュリティポリシー設定の問い合わせの前に行われる。 そうすることで、セキュリティポリシー設
定の問い合わせに使う文字列に、 ネットグループを Unix グループと同じように使うことが可能に
なるのだ。 上で述べた三回目の問い合わせは、 グループ・プロバイダー・プラグインも同時に設定
されていないかぎり、行われない。 ネットグループについての sudo による LDAP の問い合わせ
は、 実際には次のように行われる。
1. nisNetgroupTriple (ユーザ、ホスト、NIS ドメインを含む) を持ったすべての nisNetgroup
レコードと照合を行う。この問い合わせでは、 nisNetgroupTriple エントリーのホスト名が長
い形式でも短い形式でも、 あるいは、タプルにホスト名が指定されていなくても、マッチする
ことになる。 問い合わせに NIS ドメインがセットされている場合にマッチするのは、 そのド
メインを含むか、あるいは、ドメインの指定がないエントリだけである。 NIS ドメインがセッ
トされていない場合は、ワイルドカードが使用され、 どんなドメイン名にもマッチすることに
なるが、 LDAP サーバの中には、使用している NIS スキーマが、 nisNetgroupTriple に対す
るワイルドカードをサポートしていないものがあることに留意していただきたい。
2. 問い合わせを繰り返して行い、すでにマッチしたレコードを指す memberNisNetgroup エントリ
が、入れ子のように使われている nisNetgroup レコードがあれば、そうしたものを見つけ出
す。
多数のネットグループを持つサイトでは、NETGROUP_BASE を使用すると、 sudo の実行速度を大幅に
向上させることができる。
LDAP を使う場合と使わない場合の sudoers セキュリティポリシー設定の相違点
LDAP を使用した場合は、sudoers セキュリティポリシー設定の処理方法に /etc/sudoers の場合と
は微妙な違いがいくつかある。たぶん最大の違いは、 RFC に書いてあるとおり、LDAP の順序づけは
不定なので、 属性やエントリが何らかの決まった順序で返されることを期待できないことだろう。
それでも、個々のエントリに割り振られる順番については、sudoOrder によってコントロールするこ
とができる。 だが、ある特定のエントリ内での属性の順番については、 それを確定する方法は存在
しないのだ。 もっとも、あるエントリーにコマンドに関して相反するルールがある場合は、 否定す
る方が優先される。いわゆるパラノイア的動作である (それが一番すっきりしたマッチだとはかぎら
ないが)。
例を挙げてみよう。
# /etc/sudoers の場合:
# shell 以外のすべてのコマンドを許可する
johnny ALL=(root) ALL,!/bin/sh
# 次の設定は、ALL が最後にマッチするので、常にすべての
# コマンドを許可することになる
puddles ALL=(root) !/bin/sh,ALL
# 上記の johnny に相当する LDAP のエントリ:
# shell 以外のすべてのコマンドを許可する
dn: cn=role1,ou=Sudoers,dc=my-domain,dc=com
objectClass: sudoRole
objectClass: top
cn: role1
sudoUser: johnny
sudoHost: ALL
sudoCommand: ALL
sudoCommand: !/bin/sh
# 上記の puddles に相当する LDAP のエントリ:
# ALL が最後に指定されているが、LDAP のコードでは、
# よりパラノイア的な方を、指定された設定と見なすようになって
# いるため、これもまた role1 と同じように動作することに
# 注意していただきたい
dn: cn=role2,ou=Sudoers,dc=my-domain,dc=com
objectClass: sudoRole
objectClass: top
cn: role2
sudoUser: puddles
sudoHost: ALL
sudoCommand: !/bin/sh
sudoCommand: ALL
もう一つの相違は、Host、User、Runas についての否定は、 現在のところ無視されるということ
だ。 たとえば、以下に挙げるような属性は期待どおりに動作しない。
# joe 以外の全員とマッチしないどころか、
# 誰にもマッチしない
sudoUser: !joe
# joe 以外の全員とマッチしないどころか、
# joe を含む全員にマッチしてしまう
sudoUser: ALL
sudoUser: !joe
# web01 以外のすべてとマッチしないどころか、
# web01 を含むすべてのホストにマッチしてしまう
sudoHost: ALL
sudoHost: !web01
sudo 用のスキーマ
sudo の LDAP サポートを利用するためには、お使いの LDAP サーバに sudo 用のスキーマをインス
トールしなければならない。 そして、sudoUser 属性の索引を必ず作成しておく。
たぶん、sudo の配布物中には三種類のスキーマが入っていると思う。 すなわち OpenLDAP サーバ用
(schema.OpenLDAP)、 Netscape ディレクトリサーバの流れを汲むサーバ用 (schema.iPlanet)、
Microsoft Active Directory 用 (schema.ActiveDirectory) のスキーマである。
OpenLDAP 用の形式にした sudo のスキーマは、 「用例」セクションにも記載しておいた。
ldap.conf の設定
sudo は LDAP に関する設定を知るために /etc/ldap.conf を読み込む。 通例、このファイルは、
LDAP に対応しているさまざまなクライアントの間で共有されている。 それ故、設定の大部分は
sudo 専用ではない。 注意すべきは、sudo は /etc/ldap.conf を独自に解析しており、
ldap.conf(5) のマニュアルで説明されているものとは 異なるオプションをサポートしていることが
あるということだ。 ldap.conf のパスは、sudo.conf(5) ファイルでプラグインに対する引き数
ldap_conf を使用すれば、変更することができる (訳注: sudoers ポリシー・プラグインに対して指
定できる引き数については、 sudoers(5) のマニュアルの「sudoers ポリシー・プラグインを使うた
めの sudo.conf の設定」セクションに説明がある)。
もうひとつ注意していただきたいのは、 OpenLDAP ライブラリを使っているシステムでは、
/etc/openldap/ldap.conf やユーザの .ldaprc ファイルで指定しているデフォルト値が使用されな
いことである。
すなわち、/etc/ldap.conf に明示的に記載され、かつ sudo でサポートされているオプションのみ
が使用される。 設定オプションを以下に大文字で列挙するが、 解析されるときは大文字小文字は区
別されない。
パウンド記号 ('#') を使用すれば、 以下はコメントであると示すことができる。すなわち、 コメ
ントの印と、それに続くいかなるテキストも、行末に至るまで、 無視されることになる。長い行
は、行末にバックスラッシュ ('\') を置けば、継続することができる。 行頭の空白 (white
space)は、継続記号を使用している場合でも、 行頭から取り除かれることに注意していただきた
い。
BIND_TIMELIMIT seconds
BIND_TIMELIMIT パラメータでは、 LDAP サーバに接続しようとするときの待ち時間を秒数で
指定する。 URI や HOST が複数指定されている場合は、その時間だけ待ってから、 リスト中
の次のサーバに接続を試みることになる。
BINDDN DN
BINDDN パラメータでは、誰の名前で LDAP の操作を行うかを、 識別名 (DN) を使って指定す
る。これが指定されていない場合、 LDAP の操作は anonymous の名前で実行される。LDAP
サーバは、 たいていデフォルトで anonymous によるアクセスを許可しているものである。
BINDPW secret
BINDPW パラメータでは、LDAP の操作を行うときに使用するパスワードを指定する。 通
常、このパラメータは、BINDDN パラメータと組み合わせて使用する。 secret は、プレーン
テキストのパスワードでもよく、 "base64:" という接頭辞付きの、base64 でエンコードした
文字列でもよい。 たとえば、次のようなものだ。
BINDPW base64:dGVzdA==
プレーンテキストのパスワードを使用する場合、 パスワードは引用符を付けない単なる文字
列にするべきだ。 プレーンテキストのパスワード中には、コメント文字 ('#') があってはな
らない。また、バックスラッシュ ('\') による特殊文字のエスケープはサポートされていな
い。
DEREF never/searching/finding/always
検索を行うときに、alias の参照展開をどうするかを指定する。 このオプションについての
詳しい説明は、ldap.conf(5) のマニュアルにある。
HOST name[:port] ...
URI パラメータ (下記参照) が指定されていない場合は、 HOST パラメータで指定する空白
(white space) で区切ったリストが、接続する LDAP サーバになる。 各ホストにはコロン
(':') に続けて、ポート番号を書いてもよい。 HOST パラメータは非推奨であり、URI で指定
する方が望ましい。 このパラメータがあるのは、後方互換のためである。
KRB5_CCNAME file name
リモート・サーバに対して認証をするときに使用する Kerberos 5 資格証明キャッシュのパ
ス。このオプションは、SASL 認証 (下記参照) を使用するときしか意味を持たない。
LDAP_VERSION number
サーバに接続するときに使用する LDAP プロトコルのバージョン。 デフォルトの値は、プロ
トコルバージョン 3 である。
NETGROUP_BASE base
LDAP でネットグループの問い合わせを行うときに使用するベース DN を指定する。 ドメイン
が example.com ならば、たいてい ou=netgroup,dc=example,dc=com という形にな
る。NETGROUP_BASE を複数回指定してもよい。 その場合は、指定された順番で問い合わせが
行われることになる。
このオプションを使用すると、 LDAP 経由で直接ユーザのネットグループを問い合わせること
ができる。 そうする方が、sudoRole オブジェクトのうちで '+' という接頭辞を持つ
sudoUser を含んでいるものをすべて取得するよりも、 たいていの場合動作が高速にな
る。LDAP サーバによっては、 nisNetgroup オブジェクトをその nisNetgroupTriple メンバ
によって検索できるようにするためには、 使用している NIS スキーマに変更を加える必要が
あるものも存在する。 OpenLDAP の slapd の場合は、 nisNetgroupTriple アトリビュートに
以下の変更を加えなければならない。
attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
DESC 'Netgroup triple'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
NETGROUP_SEARCH_FILTER ldap_filter
sudo が LDAP でネットグループの問い合わせを行うとき、 どんな情報を返すかを限定する
LDAP のフィルター。通常 ldap_filter は、 attribute=value とか
(&(attribute=value)(attribute2=value2)) という形を取る。デフォルトの検索フィルター
は、 objectClass=nisNetgroupである。ldap_filter の指定を省略すると、 検索フィルター
が全く使われないことになる。このオプションは、 LDAP で直接ネットグループの問い合わせ
を行うときしか効果を持たない。
NETWORK_TIMEOUT seconds
BIND_TIMELIMIT の別名。OpenLDAP との互換のためにある。
PORT port_number
URI パラメータが指定されず、HOST パラメータでもポートが指定されていないときは、PORT
パラメータが LDAP サーバに接続するときのデフォルトのポートを示すことになる。 PORT パ
ラメータが使用されていない場合、デフォルトのポートは LDAP では 389 番、LDAP over TLS
(SSL) では 636 番である。 PORT パラメータは非推奨であり、URI で指定する方が望まし
い。 このパラメータは後方互換のためにのみ存在している。
ROOTBINDDN DN
ROOTBINDDN パラメータでは、 sudoers セキュリティポリシー設定の問い合わせのような、
特権的な LDAP 操作をするとき、誰の名前で行うかを識別名 (DN) を使って指定する。その名
前に対応するパスワードは、 sudo.conf(5) の中でプラグインに対する引き数 ldap_secret
によってパスを指定されたファイルに書き込んでおくべきだ。 このパスのデフォルトは
/etc/ldap.secret である (訳注: sudoers プラグインに対する引き数 ldap_secret について
は、sudoers(5) のマニュアルに記述がある)。 このパラメータが設定されていない場合は、
BINDDN で指定した名前があるならば、それが使用される。
ROOTUSE_SASL on/true/yes/off/false/no
ROOTUSE_SASL を有効にすると、 sudo のような特権的なプロセスから LDAP サーバに接続す
るときに SASL 認証が可能になる。
SASL_AUTH_ID identity
LDAP サーバに接続するときに使用する SASL ユーザ名。 デフォルトでは、sudo は
anonymous 接続を使用する。 このオプションは、SASL 認証を使用するときしか意味を持たな
い。
SASL_SECPROPS none/properties
SASL セキュリティ・プロパティを指定する。プロパティなしならば、 none である。詳細に
ついては、 SASL プログラマーズ・マニュアルを参照すること。 このオプションは、SASL 認
証を使用するときしか意味を持たない。
SSL on/true/yes/off/false/no
SSL パラメータが on, true, yes になっていると、 LDAP サーバと通信する際に、常に TLS
(SSL) の暗号化を使用することになる。 普通、そのためには、636 番ポート (ldaps) でサー
バに接続していなければならない。
SSL start_tls
SSL パラメータを start_tls に設定すると、LDAP サーバへの接続を平文で開始し、 バイン
ド操作のために認証情報を送信する直前に、TLS の暗号化を始めることになる。 これに
は、暗号化された通信のために専用のポートを必要としないという長所がある。 このパラ
メータをサポートしているのは、 OpenLDAP サーバや Tivoli ディレクトリ・サーバのような
start_tls 拡張に対応している LDAP サーバのみである。
SUDOERS_BASE base
sudo が LDAP の問い合わせを行うときに使用するベース DN を指定する。 ドメインが
example.com ならば、普通 ou=SUDOers,dc=example,dc=com という形になる。SUDOERS_BASE
を複数回指定してもよい。 その場合は、指定された順番で問い合わせが行われることにな
る。
SUDOERS_DEBUG debug_level
sudo が LDAP の問い合わせをするときのデバッグレベルを決める。 デバック情報の出力先は
標準エラーである。値を 1 にすると、 多からず少なからずほどほどのデバック情報が表示さ
れる。 値を 2 にすると、マッチの結果そのものも出力される。 実用環境では、このパラ
メータを設定するべきではない。 ユーザが余計な情報に混乱しかねないからだ。
SUDOERS_DEBUG パラメータは非推奨であり、 将来のリリースでは廃止されることになる。今
では同じ情報が、 sudo のデバッグ用フレームワークを通してログに記録されるようになって
いる。 debug_level の値に 1 や 2 を指定する代わりに、サブシステムとして "ldap" を使
用し、重大度 (priority) にそれぞれ diag や info を指定すればよいのだ。 sudo のデバッ
グを設定する方法について詳細を知りたければ、 sudo.conf(5) のマニュアルをご覧になると
よい (訳注: sudoers(5) のマニュアルの「デバッギング」セクションも参照)。
SUDOERS_SEARCH_FILTER ldap_filter
sudo が LDAP の問い合わせを行うとき、 どんな情報を返すかを限定する LDAP のフィル
ター。通常 ldap_filter は、 attribute=value とか
(&(attribute=value)(attribute2=value2)) という形を取る。デフォルトの検索フィルター
は、objectClass=sudoRole である。 ldap_filter の指定を省略すると、検索フィルターが全
く使われないことになる。
SUDOERS_TIMED on/true/yes/off/false/no
属性 sudoNotBefore や sudoNotAfter を評価するか、しないかを指定する。 この二つの属性
によって日時制限のある sudoers セキュリティポリシー設定のエントリを実現している。
TIMELIMIT seconds
TIMELIMIT パラメータでは、 LDAP の問い合わせに対して応答が返ってくるまでの待ち時間を
秒数で指定する。
TIMEOUT seconds
TIMEOUT パラメータでは、 様々な LDAP API から応答が返ってくるまでの待ち時間を秒数で
指定する。
TLS_CACERT file name
TLS_CACERTFILE の別名。OpenLDAP との互換のためにある。
TLS_CACERTFILE file name
認証局の証明書を一つにまとめたファイルのパス。たとえば、 /etc/ssl/ca-bundle.pem と
いったファイルであり、 正当なものだとクライアントが認識している、 すべての認証局の証
明書がそこに入っている。 このオプションをサポートしているのは、OpenLDAP ライブラリだ
けである。 Netscape 由来の LDAP ライブラリは、認証局とクライアント、 両方の証明書に
対して、同一の証明書データベースを使用する (TLS_CERT を参照)。
TLS_CACERTDIR directory
TLS_CACERTFILE に似ているが、ファイルではなく、たとえば /etc/ssl/certs といったディ
レクトリであり、 認証局の証明書が 1 認証局 1 ファイルの形でそこに入っている。
TLS_CACERTDIR で指定したディレクトリは、TLS_CACERTFILE の後でチェックされる。このオ
プションをサポートしているのは、 OpenLDAP ライブラリだけである。
TLS_CERT file name
クライアントの証明書が入っているファイルのパス。この証明書は、 LDAP サーバに対するク
ライアントの認証に使用できる。 証明書のタイプは、利用する LDAP ライブラリによって異
なっている。
OpenLDAP:
tls_cert /etc/ssl/client_cert.pem
Netscape 由来:
tls_cert /var/ldap/cert7.db
Tivoli ディレクトリ・サーバ:
使用しない。TLS_KEY で指定するキー・データベースに、 キーと証明書の両方が入っ
ている。
Netscape 由来のライブラリを使う場合は、 このファイルに認証局の証明書も入れるこ
とができる。
TLS_CHECKPEER on/true/yes/off/false/no
TLS_CHECKPEER が有効になっていると、 LDAP サーバの TLS 証明書が正当かどうかチェック
が行われる。 LDAP サーバの証明書が正当であることを確認できない場合 (たいていは、署名
している認証局が未知 (unknown) であることが理由だ)、 sudo はそのサーバに接続すること
ができない。 TLS_CHECKPEER が無効になっている場合は、チェックが行われない。 この
チェックをやらないことにすると、サーバーの身元の正真性を確認できないので、 中間者攻
撃の可能性が生じることに気をつけていただきたい。 可能ならば、認証局の証明書は、その
正当性のチェックができるように、 手元のマシンにインストールしておくべきである。この
オプションは、 Tivoli ディレクトリ・サーバの LDAP ライブラリではサポートされていな
い。
TLS_KEY file name
TLS_CERT で指定した証明書に対応する、秘密鍵が入っているファイルのパス。 この秘密鍵は
パスワードでプロテクトされていてはならない。 鍵のタイプは利用する LDAP ライブラリに
よって異なっている。
OpenLDAP:
tls_key /etc/ssl/client_key.pem
Netscape 由来:
tls_key /var/ldap/key3.db
Tivoli ディレクトリ・サーバ:
tls_key /usr/ldap/ldapkey.kdb
Tivoli LDAP ライブラリを使用する場合は、 このファイルに認証局やクライアントの証明書
も入れることができる。 また、暗号化することもできる。
TLS_CIPHERS cipher list
TLS_CIPHERS パラメータを使用すると、 管理者が TLS (SSL) 接続に使用可能な暗号アルゴリ
ズムを限定することができる。 有効な暗号のリストについては、 OpenLDAP や Tivoli ディ
レクトリ・サーバのマニュアルを参照していただきたい。 Netscape 由来のライブラリは、こ
のオプションをサポートしていない。
TLS_KEYPW secret
TLS_KEYPW では、 Tivoli ディレクトリ・サーバの LDAP ライブラリを使っているクライアン
トで、 キー・データベースを復号するのに使用するパスワードを指定する。 secret は、プ
レーンテキストのパスワードでもよく、 "base64:" という接頭辞付きの、base64 でエンコー
ドした文字列でもよい。 たとえば、次のようなものだ。
TLS_KEYPW base64:dGVzdA==
プレーンテキストのパスワードを使用する場合、 パスワードは引用符を付けない単なる文字
列にするべきだ。 プレーンテキストのパスワード中には、コメント文字 ('#') があってはな
らない。また、バックスラッシュ ('\') による特殊文字のエスケープはサポートされていな
い。 このオプションを使用するのならば、 /etc/ldap.conf を誰にでも読める状態にしては
いけない。 さもないと、パスワードを公開してしまうことになる。 パスワードの公開を避け
る別の方法としては、 stash file を使用することも可能だ。そうすれば、 パスワードを暗
号化した形で格納することができる (下記参照)。
TLS_KEYPW が指定されていない場合、 stash file が存在すれば、それを使用することにな
る。stash file は、 TLS_KEY で指定されるファイルと同じパスを持たなければならないが、
拡張子には .kdb の代わりに、.sth を使わなければならない。 たとえば、ldapkey.sth と
いった具合だ。 Tivoli ディレクトリ・サーバ出荷時のデフォルトの ldapkey.kdb は、
ssl_password というパスワードを使って暗号化されている。 gsk8capicmd というユーティリ
ティを使用すれば、 キー・データベースの管理と、stash file の作成を行うことができる。
このオプションをサポートしているのは、Tivoli LDAP ライブラリだけである。
TLS_RANDFILE file name
TLS_RANDFILE では、random デバイスを持っていないシステムのために エントロピー・ソー
スのパスを指定する。 これは通例、prngd や egd と組み合わせて使用するものだ。 このオ
プションをサポートしているのは、OpenLDAP ライブラリだけである。
URI ldap[s]://[hostname[:port]] ...
接続する一個以上の LDAP サーバ の URI を、空白 (white space) で区切ったリストの形で
指定する。プロトコルは ldap と ldaps のどちらでもよい。後者は TLS (SSL) 暗号化に対応
しているサーバの場合である。 ポートを指定しないときのデフォルトは、 ldap:// では 389
番ポート、ldaps:// では 636 番ポートである。 hostname を一つも指定しないと、 sudo は
localhost に接続することになる。URI の行が二行以上ある場合は、 URI の行に複数のエン
トリがあるときと同様に処理される。 OpenSSL ライブラリを使用しているシステムのみが、
ldap:// と ldaps:// 両方の URI を混ぜて使うことに対応している。 たいていの商用 Unix
では Netscape 由来のライブラリや Tivoli LDAP ライブラリが使用されているが、 そうした
ライブラリはどちらか一方に対応することしかできない。
USE_SASL on/true/yes/off/false/no
LDAP サーバが SASL 認証をサポートしているとき、 USE_SASL を有効にする。
ROOTSASL_AUTH_ID identity
ROOTUSE_SASL が有効なとき使用する SASL ユーザ名。
「用例」セクションにある ldap.conf のくだりも参照していただきたい。
nsswitch.conf の設定
ビルド時に無効にしないかぎり、sudo はネームサービス・スイッチ・ファイル /etc/nsswitch.conf
を調べて、 sudoers セキュリティポリシーの設定を参照する順番を決める。 すなわ
ち、/etc/nsswitch.conf で sudoers: という文字列に始まる行を探し、 その行によって参照順を決
定するのである。 気をつけていただきたいのは、sudo は参照中、 マッチする項目に一度出会った
からと言って、そこで参照を終わりにしないことだ。 後でマッチしたものが前にマッチしたものよ
りも優先されるのである。 以下の参照元が有効である。
files /etc/sudoers から sudoers セキュリティポリシーの設定を読み込む
ldap LDAP から sudoers セキュリティポリシーの設定を読み込む
なお、[NOTFOUND=return] の記述があると、 先行する参照元にユーザが見つからなかった場合、参
照を中断することになる。
最初に LDAP を参照し、その後で (もし存在するならば) ローカルマシン上の sudoers ファイルを
調べるには、次のように指定する。
sudoers: ldap files
ローカルマシン上の sudoers ファイルをまったく無視するには、 次のようにする。
sudoers: ldap
/etc/nsswitch.conf ファイルが存在しなかったり、存在しても sudoers の行がなかったりした場合
は、次のデフォルト設定が使用される。
sudoers: files
使用しているオペーレーティング・システムが nsswitch.conf ファイルを使用しない場合で
も、sudo は、AIX のシステム以外では (次のセクションを参照)、/etc/nsswitch.conf をサポート
していることに注意していただきたい。
netsvc.conf の設定
AIX システムでは、/etc/nsswitch.conf ではなく、 /etc/netsvc.conf ファイルを調べに行
く。sudo としては、 netsvc.conf を nsswitch.conf のバリエーションとして扱うだけだ。 それ
故、上のセクションの記述のうち、ファイルの書式に関係のないものは、 ここでも当てはまること
になる。
最初に LDAP を参照し、その後で (もし存在するならば) ローカルマシン上の sudoers ファイルを
調べるには、次のように指定する。
sudoers = ldap, files
ローカルマシン上の sudoers ファイルをまったく無視するには、 次のようにする。
sudoers = ldap
LDAP を正式の参照元と見なし、LDAP にユーザが見つからなかったときのみ、 ローカルの sudoers
ファイルを使用する。
sudoers = ldap = auth, files
注意していただきたいが、上記の例において、auth 修飾子が影響を及ぼすのは、 ユーザを検索する
ときだけである。 Defaults エントリについては、LDAP と sudoers の両方が参照される。
/etc/netsvc.conf ファイルが存在しなかったり、存在しても sudoers の行がなかったりした場合
は、次のデフォルト設定が使用される。
sudoers = files
sssd との統合
System Security Services Daemon (SSSD) を使用しているシステムで、 sudo が SSSD サポートを
有効にしてビルドされている場合は、 LDAP の sudoers ルールをキャッシュするのに SSSD を使用
することができる。 sudoers の参照先として SSSD を使用するためには、 /etc/nsswitch.conf の
sudoers のエントリで ldap の代わりに sssd を使わねばならない。なお、SSSD 用の sudo のバッ
クエンドは、 /etc/ldap.conf ファイルを使用しないことに気をつけていただきたい。 SSSD と共に
使用するときの sudo の設定についてより詳しい情報をお知りになりたかったら、 sssd-sudo(5) を
ご覧になるとよい。
ファイル
/etc/ldap.conf LDAP の設定ファイル
/etc/nsswitch.conf sudoers セキュリティポリシー設定の参照元の順番を決める
/etc/netsvc.conf AIX で sudoers セキュリティポリシー設定の参照元の順番を決める
用例
ldap.conf の一例
# URI または host:port の組み合わせを一つ以上指定する。
# どちらも指定されていない場合、sudo はデフォルトの localhost と
# 389 番ポートを使用する。
#
#host ldapserver
#host ldapserver1 ldapserver2:390
#
# host がポートなしで指定されている場合のポート番号。
# デフォルトは 389 である。
#port 389
#
# URI による指定は、host と port による指定に優先する。
uri ldap://ldapserver
#uri ldaps://secureldapserver
#uri ldaps://secureldapserver ldap://ldapserver
#
# LDAP サーバに接続しようとしているときの、秒単位の待ち時間。
bind_timelimit 30
#
# LDAP に問い合わせを行っているときの、秒単位の待ち時間。
timelimit 30
#
# 必ず設定すること。さもないと、sudo は LDAP を無視することになる。
# 複数回指定してもよい。
sudoers_base ou=SUDOers,dc=example,dc=com
#
# LDAP で sudoers セキュリティポリシー設定を問い合わせる際の
# マッチングについて詳細情報を表示する。
#sudoers_debug 2
#
# sudoers セキュリティポリシー設定中で日時制限のあるエントリの
# サポートを有効にする。
#sudoers_timed yes
#
# LDAP の操作を行う者の認証情報 (設定する、しないは任意)。
#binddn <who to search as>
#bindpw <password>
#rootbinddn <who to search as, uses /etc/ldap.secret for bindpw>
#
# LDAP プロトコルのバージョン。デフォルトは 3 である。
#ldap_version 3
#
# LDAP 接続を暗号化したい場合に設定する。
# 通例、ポートを 636 (ldaps) にすることも必要。
#ssl on
#
# ポート 389 を使用し、バインド操作のために認証情報が
# 送信される直前に、暗号化セッションに切り替えたい場合に設定する。
# これをサポートしているのは、OpenLDAP のような start_tls 拡張に
# 対応している LDAP サーバだけである。
#ssl start_tls
#
# さらに以下の TLS 関連オプションを使うことで SSL/TLS 接続の
# 細かい調整ができる。
#
#tls_checkpeer yes # サーバの SSL 証明書の正当性をチェックする。
#tls_checkpeer no # サーバの SSL 証明書の正当性をチェックしない。
#
# tls_checkpeer を有効にするときは、 tls_cacertfile か
# tls_cacertdir のどちらかを指定すること。tls_cacertfile や
# tls_cacertdir は OpenLDAP の使用時のみ使える。
#
#tls_cacertfile /etc/certs/trusted_signers.pem
#tls_cacertdir /etc/certs
#
# /dev/random がないシステムでは、下記の設定を PRNGD、あるいは
# EGD.pl と一緒に使用すれば、暗号セッション用の鍵を生成するための
# 乱数プールの種を供給できる。このオプションが使えるのは、
# OpenLDAP を使用しているときだけである。
#
#tls_randfile /etc/egd-pool
#
# 使用する暗号を限定することができる。どの暗号が使えるかに
# ついては、SSL の文書を参照すること。このオプションが
# 使えるのは、OpenLDAP を使用しているときだけである。
#
#tls_ciphers <cipher-list>
#
# sudo は LDAP サーバと交信するときに、クライアントの証明書を
# 提示することができる。
# 注意:
# * 両方の行を同時に有効にすること。
# * キーファイルをパスワードでプロテクトしてはいけない。
# * キーファイルが読めるのは root だけにするのを忘れずに。
#
# OpenLDAP の場合:
#tls_cert /etc/certs/client_cert.pem
#tls_key /etc/certs/client_key.pem
#
# SunONE や iPlanet LDAP (訳注: Netscape 由来) の場合:
# こちらの場合は、tls_cert や tls_key で指定するのは、証明書や
# キーファイルの入っているディレクトリでもよく、ファイルそのものの
# パスでもよい。前者の場合、ディレクトリ中のファイルは、所定の名前
# (たとえばcert8.db と key4.db) でなければならない。もっとも、
# ファイルのパスを指定した場合は、バージョン 5.0 の LDAP SDK には
# バグがあるので、ファイル名によってはうまく動作しないことがある。
# この理由から、tls_cert や tls_key には、ファイル名ではなく、
# ディレクトリを指定する方をお薦めする。
#
# tls_cert で指定した証明書のデータベースには、認証局の証明書と
# クライアントの証明書が、どちらか一方だけ入っていてもよく、
# 両方入っていてもよい。クライアントの証明書が入っている場合は、
# tls_key も指定するべきである。
# 後方互換のため、tls_cert のかわりに sslpath を使うこともできる。
#tls_cert /var/ldap
#tls_key /var/ldap
#
# LDAP に SASL 認証を使用する場合 (OpenSSL)
# use_sasl yes
# sasl_auth_id <SASL user name>
# rootuse_sasl yes
# rootsasl_auth_id <SASL user name for root access>
# sasl_secprops none
# krb5_ccname /etc/.ldapcache
OpenLDAP 用の sudo のスキーマ
下記のスキーマは OpenLDAP 用の形式になっており、 sudo のソースやバイナリの配布には
schema.OpenLDAP として収録されている。その schema.OpenLDAP ファイルをスキーマ・ディレクト
リ (たとえば /etc/openldap/schema) にそのままコピーし、適切な include 行を slapd.conf に追
加して、 slapd をリスタートすればよい。
attributetype ( 1.3.6.1.4.1.15953.9.1.1
NAME 'sudoUser'
DESC 'User(s) who may run sudo'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.2
NAME 'sudoHost'
DESC 'Host(s) who may run sudo'
EQUALITY caseExactIA5Match
SUBSTR caseExactIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.3
NAME 'sudoCommand'
DESC 'Command(s) to be executed by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.4
NAME 'sudoRunAs'
DESC 'User(s) impersonated by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.5
NAME 'sudoOption'
DESC 'Options(s) followed by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.6
NAME 'sudoRunAsUser'
DESC 'User(s) impersonated by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.7
NAME 'sudoRunAsGroup'
DESC 'Group(s) impersonated by sudo'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributetype ( 1.3.6.1.4.1.15953.9.1.8
NAME 'sudoNotBefore'
DESC 'Start of time interval for which the entry is valid'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
attributetype ( 1.3.6.1.4.1.15953.9.1.9
NAME 'sudoNotAfter'
DESC 'End of time interval for which the entry is valid'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
attributeTypes ( 1.3.6.1.4.1.15953.9.1.10
NAME 'sudoOrder'
DESC 'an integer to order the sudoRole entries'
EQUALITY integerMatch
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL
DESC 'Sudoer Entries'
MUST ( cn )
MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $
sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $
sudoOrder $ description )
)
関連項目
ldap.conf(5), sssd-sudo(5), sudo.conf(5), sudoers(5)
作者
多数の人々が長年に渡って sudo の開発に携わってきた。 当バージョンは主として次の者が書いた
コードからできている。
Todd C. Miller
sudo の開発に貢献してくださった方々の詳細なリストについては、 配布物中の CONTRIBUTORS ファ
イルをご覧になっていただきたい。 (https://www.sudo.ws/contributors.html)
警告
LDAP を使用する sudoers セキュリティポリシーの設定と sudoers ファイルによる設定では、設定
を解析する仕方に相違があるので、 注意していただきたい。詳細については、「LDAP を使う場合と
使わない場合の sudoers セキュリティポリシー設定の相違点」のセクションを参照すること。
バグ
sudo にバグを発見したと思ったら、https://bugzilla.sudo.ws/ にアクセスして、バグレポートを
提出していただきたい。
サポート
ある程度の無料サポートが sudo-users メーリングリストを通して利用できる。 購読やアーカイブ
の検索には、次の URL を御覧になるとよい。 https://www.sudo.ws/mailman/listinfo/sudo-users
免責
sudo は「現状のまま」提供される。 明示的な、あるいは黙示的ないかなる保証も、 商品性や特定
目的への適合性についての黙示的な保証を含め、 またそれのみに止まらず、これを否認する。詳細
な全文については、 sudo と一緒に配布されている LICENSE ファイルや、 次の Web ページをご覧
いただきたい。 https://www.sudo.ws/license.html