SELinuxのオーバーヘッド

以下、適当な測定の結果なので、正確性に欠ける可能性があります。
むやみに引用しないほうがいいです。

ちょっと測ってみると、Pentiumなマシンでは、
1byteのreadとか単にopenするだけのオーバーヘッドは10-20%ぐらい
(SELinux無しと比べて）。
1byteじゃなくて、何バイトも読むとオーバーヘッドは消える。

createとunlinkのオーバーヘッドは結構あった。
0k byte createの時は2倍ぐらい。
探ってみると、
セキュリティチェック関数が多すぎるようだ。
AVCの処理は実はボトルネックになってないようだ。軽い。
avcの処理を空にしても、オーバーヘッドはあまり変わらない。
id:omokさんの作った資料を見ると、
http://www.selinux.gr.jp/LIDS-JP/systemcalls.html
http://www.selinux.gr.jp/LIDS-JP/systemcalls/systemcalls_2_6_20_mapping_with_selinux.xls
sys_creatから、以下が呼び出し。

security_inode_follow_link(path->dentry, nd);
security_file_free(file)
security_inode_setattr(dentry, attr)
security_inode_setattr(dentry, attr);
selinux_get_inode_sid
security_inode_permission(inode, MAY_EXEC, nd);
security_inode_permission(inode, mask, nd);
security_inode_permission(inode, MAY_EXEC, nd)
capable(CAP_DAC_OVERRIDE)
capable(CAP_DAC_READ_SEARCH)
security_inode_create(dir, dentry, mode);
capable(CAP_SYS_ADMIN)
security_file_alloc(f)

大量にチェックしてる。。
たぶん、これだけじゃなくて、
ラベルの確保でもオーバーヘッドが生じていると見た。
ファイルを生成すると、ラベルを生成、付与する必要が出てくる。
何かと重そうだ。

SELinuxのオーバーヘッドは、
0k byteのcreateをしまくる場合、問題になるが、そんな場合はあるのだろうか。

open以外にreadもチェックすることの意義

TOMOYO Linuxは, openした後、
その後のreadシステムコールなどは、セキュリティチェックをしてないようだ。
なので、openのオーバーヘッドはあるが、readのオーバーヘッドは無い。
http://tomoyo.sourceforge.jp/wiki/?Performance

一方、SELinuxは、openの時もチェックするし、readの時もチェックする。
openの時は、開くファイルのタイプを。
readの時は、ファイル識別子のタイプに対して。

なので、open,read両方の時にSELinuxによるオーバーヘッドが発生する。
このメリットは何なのだろうか？？？
直感的には、より堅そうだが。
オーバーヘッドに見合ったメリットはあるのかな。
結局情報フロー制御のためには必須の要素になるのか？
ファイル識別子ってのも、オブジェクトの一つだし。。