SUDOERS.LDAP

名前

説明

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 コンテナ

[訳注]:

ここで言うコンテナ (容器、入れもの) とは、データを格納するためではなく、 データを含む下位のエントリをまとめておくために存在する上位エントリのことである。 たとえば、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 セキュリティポリシーの設定を照合するときの詳細

/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 セキュリティポリシー設定の相違点

それでも、個々のエントリに割り振られる順番については、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 の配布物中には三種類のスキーマが入っていると思う。 すなわち OpenLDAP サーバ用 (schema.OpenLDAP)、 Netscape ディレクトリサーバの流れを汲むサーバ用 (schema.iPlanet)、 Microsoft Active Directory 用 (schema.ActiveDirectory) のスキーマである。

OpenLDAP 用の形式にした sudo のスキーマは、 「用例」セクションにも記載しておいた。  

ldap.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 の設定

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 の設定

最初に 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 との統合

ファイル

/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 のスキーマ

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 ) )

関連項目

作者

Todd C. Miller

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

警告

バグ

サポート

免責

関連キーワード

Linux マニュアル 一覧

[man1] [man2] [man3] [man4] [man5] [man6] [man7] [man8]
[a] [b] [c] [d] [e] [f] [g] [h] [i] [j] [k] [l] [m] [n] [o] [p] [q] [r] [s] [t] [u] [v] [w] [x] [y] [z]

Index

名前

説明

LDAP の SUDOers コンテナ

LDAP を使って sudoers セキュリティポリシーの設定を照合するときの詳細

LDAP を使う場合と使わない場合の sudoers セキュリティポリシー設定の相違点

sudo 用のスキーマ

ldap.conf の設定

nsswitch.conf の設定

netsvc.conf の設定

sssd との統合

ファイル

用例

ldap.conf の一例

OpenLDAP 用の sudo のスキーマ

関連項目

作者

警告

バグ

サポート

免責