Next: 8 デバイスファイルのアクセス制御:allowdev
Up: SPDL仕様書 ver 2.1.
Previous: 6 ドメイン遷移
Contents
Subsections
7.1 allow
- 書式
- allow filename label [r],[w],[x],[s],[o],[t],[a],[c],[e],[dx];
- 意味
- ファイルへのアクセスを許可します
- ファイル名の指定
- パーミッションの意味
- r(Read)
ファイルの読み込み
- w(Write)
ファイル、ディレクトリの書き込み、生成、消去、追記。
ただし、デバイスファイルに関する操作は許可されません。デバイス
ファイルに対してもアクセスを許可したい場合は、allowpriv
devcreate(デバイスの生成のみが許可されます)またはallowdevを使う必要があります。
- x(eXecute)
ファイルの実行
- s(Search)
ディレクトリの中身の閲覧。ファイルに対して設定しても何も起こり
ません。ディレクトリ以下のファイルの読み込みを許可したい場合はr
と一緒に設定します。
- 例
{
domain httpd_t;
...
allow /var/www/** r,s;
....
httpd_tは、/var/www以下のファイル、ディレクトリをサブディレクト
リを含めて全て読み込みを許可されています。
- 詳細パーミッション
s,r,x,wパーミッション以外にも、o,t,a,c,eというパーミッションを使
うこともできます。これらは、wパーミッションを分割したものです。
- o: Overwrite
ファイルの上書き保存のみを許可します。ファイルの消去や生
成は許可されません。
- t: seTattr
ファイルの属性(所有者など)を変更します。なお、SELinuxのラベル情報は変更できません。
- a: Append
ファイルを追記モードでオープンすることを許可します。
- c: Create
ファイルの生成を許可します。
Allow to create file.
- e: Erase
ファイルの消去を許可します。
- ドメイン遷移パーミッション:dx
dx という特殊なパーミッションが用意されています。もし、ド
メインがそのプログラムに対して定義されていれば、そのプログラムに
新たなドメインが付与されて動作します。
例:
{
domain httpd_t;
program /usr/sbin/httpd;
allow /var/www/cgi-bin/test.cgi r,s,dx;
}
{
domain cgi_t;
program /var/www/cgi-bin/test.cgi;
allow ............
}
この場合 httpd_tドメインは、test.cgiに対してdxパーミッションが
許可されています。test.cgiには、cgi_tというドメインを割り当てる
設定がされているため、cgi_tドメインが割り当てられます。
なお、通常の「x」パーミッションですと、test.cgiは、httpd_tのま
ま動作してしまいます。
program /var/www/cgi-bin/test.cgi;という設定は、unconfinedドメイ
ンから起動した場合にcgi_tドメインを割り当てる設定であるため、httpd_t
から起動した場合には、cgi_tは割り当てられません。
- ホームディレクトリについての制限事項
個々のユーザーのホームディレクトリにdenyを記述しても無視されます。
例:
deny /home/ynakam/public_html;
- 書式
deny filename;
- 意味
allow文に対する制約を記述したり、allowをキャンセルするのに使われます。
- 例
- 例1 1: 制約の記述
*constraintsという名前のファイル名
deny /etc/shadow;
*httpd_t.spというファイル
{
domain httpd_t;
include constraints;
allow /etc/* r,s;
}
include constraints;では、constraintsという名前のファイルで行った
設定、つまり、deny /etc/shadowが設定されます。以下と同じ意味です。
{
domain httpd_t;
include constraints;
deny /etc/shadow;
allow /etc/* r,s;
}
これの意味ですが、httpd_tドメインは、/etcの下にあるファイルに対して読み
込みができます。
しかし、/etc/shadowにはアクセスはできません。
/etc/shadowにアクセスするには、
allow /etc/shadow r,s; と、明示的に書かねばなりません。denyは、設
定ミスを防ぐのに役に立ちます。
- 例2: allowのキャンセル
{
domain httpd_t;
allow /etc/* r,s;
deny /etc;
allow /etc/* r,s; は、deny /etc;を記述することでキャンセルされます。
- allowがコンフリクトしたらORを取る
- 例
domain foo_t;
allow /var/** r;
allow /var/** s;
foo_t は /var/**に、 r,sが許可されます。
domain foo_t;
allow /var/run/* r;
allow /var/run/** w;
foo_tは、/var/run直下のファイルにrパーミッションが許可されます。
一方、/var/run以下のファイル・ディレクトリに対し、サブディレクトリ含めて
wパーミッションが許可されます。
- 親ディレクトリ、子ディレクトリで衝突した場合
domain foo_t;
allow /var/** r;
allow /var/run/** w;
foo_tは、/var以下にrパーミッションが許可されますが、
/var/run以下についてだけは、wパーミッションが許可されます。
- allow/denyが衝突したら、前にされていた設定を打ち消し
- 例:
domain foo_t;
allow /foo/* r,s;
deny /foo/* ;
allow /foo/* r,sが打ち消されます。
domain foo_t;
deny /foo/* ;
allow /foo/* r,s;
deny /foo/* が打ち消されます。
domain foo_t;
allow /foo/bar/** r,s;
deny /foo/** ;
allow /foo/bar/** r,sが打ち消されます。
- 例外
domain foo_t;
deny /foo/bar/**;
allow /foo/** r,s;
deny /foo/bar/** は打ち消されません。 not
cancelled. denyをキャンセルするには、常にdenyされたディ
レクトリを直接指定したallowを書く必要があります。(今回の
場合 allow /foo/bar/** r,s;のように書く必要があり
ます)
以下のファイルに対するアクセス制御は特殊な扱いになっています。
- /dev/tty* /dev/pts /dev/ptmx, /dev/vcs*,/dev/vcsa*
これらは端末に関するファイルですが、allowを書いても何も起こりません。これらのファイ
ルへのアクセスは、allowdev文で行うようになっています。
- /proc, /sysfs, /selinux, /dev/tmpfs
これらのファイルに対する設定は、何も起こりません。内部的なことを
いうと、SELinuxは、これらのファイルがマウントされているファイル
システムをサポートしていないためです。allowfsを使うことで一部設
定することはできます。また、/selinux以下へのアクセス制御は
allowpriv getsecurity, setsecurityで制御できます。
パスの途中にシンボリックリンクが含まれるようなファイル名は、無視されま
す。
例えば、
allow /etc/init.d/httpd r;
は無視されます。(init.dは、rc.d/init.dへのシンボリックリンクだか
らです)。
Linuxシステムでは、ハードリンクを使うことで、ファイルの中身を複数
のファイル名で参照することができます。ハードリンクは、デフォルト
ではほとんど使われていないため、以下の内容を気にする場面はほとん
ど現れませんが、セキュリティ上知っておいたほうがいいでしょう。
SPDLでは、ハードリンクは以下のルールで処理されます。
ファイルの中身が複数のハードリンクで参照される場合、元々存在
したファイル名を記述する必要がある。それ以外のファイル名が指定さ
れた場合は無視される。
例えば、/etc/shadow と/var/chroot/etc/shadowがハードリンクされて
いたとします。/etc/shadowが元々存在していたとすると、/etc/shadow
(と/var/chroot/etc/shadow)の中身を見るためには、allow
/etc/shadow rと記述する必要があります。allow /var/chroot/etc/shadow r
と記述しても無視されます。
ハードリンクが複数存在する場合、どのファイル名を「元々存在するファ
イル名」とするかの基準が気になるところです。以下の基準で
「元々存在するファイル名」が判定されます。以下で出てくる例では、
/etc/shadow, /var/shadowがハードリンクされたファイルだと仮定しま
す。
- 全ポリシ中で、一つのファイル名に対する設定しか書かれていな
い場合、そのファイル名が「元々存在するファイル名」になりま
す
例: allow /etc/shadow rがある場所で記述されているとします。
そして、/var/shadowを使った設定はどこにも記述されていない
とします。この場合は、/etc/shadowが、元々存在するファイル
名として取り扱われます。
- 複数のファイル名に対する設定が記述されていた場合、名前が一
番若いものが、「元々存在するファイル名」になります。
例: allow /etc/shadow r,allow /var/shadow r; という設定が
記述されていたとします。この場合、「/etc/shadow」が、「元々
存在するファイル名」になります。なぜなら、/etc/shadowのほ
うが名前が若いからです。
- ハードリンクされたファイル名を使った設定がどこにも記述され
てないときは、所属ディレクトリ名を比較して、所属ディレクト
リ名が最も大きいものが「元々存在するファイル名」となります。
例: /etc/shadow, /var/shadowを使った設定がどこにも記述され
ていない場合、/var/shadowが「元々あるファイル名」となりま
す。なぜなら、/var/ /etcだからです。
しかし、どのハードリンク名が「元々存在するファイル名」か分からな
い場合は、全ての名前を使う手もあります。例えば、
allow /etc/shadow r;
allow /var/shadow r;
のように記述した場合、どちらかの設定は無視されるだけで、無害です。
以上のハードリンクの取り扱いは、パス名ベースのセキュリティの「抜
け穴」を防ぐために必要なものです。
この取り扱いがなかったとすると、
例えば、/etc/shadowのハードリンクが、なんらかの手で
/var/www/html/shadowに作られてしまうと、Webサーバーから
/etc/shadowの中身を覗けてしまうことになります。これを防ぐために、
ハードリンクされたファイルの中身にアクセスするには、「一つのファ
イル名」しか使えないようにする必要があるわけです。パス名ベースの
セキュリティの問題点については、
http://securityblog.org/brindle/2006/04/19
に詳しいです。
Next: 8 デバイスファイルのアクセス制御:allowdev
Up: SPDL仕様書 ver 2.1.
Previous: 6 ドメイン遷移
Contents
Yuichi Nakamura
2006-12-27