Tetsuo Handa
from-****@I-lov*****
2006年 11月 12日 (日) 15:31:28 JST
TOMOYO
Fork 熊猫です。
突然ですが RFC（Request For Comment：コメント募集）です。
TOMOYO Linux 1.3 ではドメイン単位でプロファイル番号を割り当てることにより、
ポリシーの積み上げ学習が可能になりました。しかし、それだけではありません。
ドメイン単位で強制アクセス制御を行うかどうかも指定できるようになったわけです。
1.2 までは原則として全てのドメインに対して単一プロファイルによる強制アクセス制御が
適用されるため、メンテナンス用途などで強制アクセス制御を適用させたくないドメインを
定義するために trust_domain というキーワードが用意されていました。
（ 1.3 でも 1.2 との互換性のために残しています。）
trust_domain というキーワードで指定されたドメイン名で始まるドメインについては、
（１）ドメイン単位のアクセス制御が適用されない
（２） initializer キーワードで指定されたプログラムが実行されない限りその信頼済みドメインに留まる
という仕様になっています。
しかし、ドメイン単位でプロファイル番号を割り当てることで
強制アクセス制御を行うかどうか指定できるようになった現在では、
（１）の機能は不要になりました。さらに、強制アクセス制御が有効なプロファイルが
割り当てられていても trust_domain キーワードでも指定されているとドメイン単位の
強制アクセス制御が適用されなくなってしまうという落とし穴もあります。
（そのため、 1.3 では trust_domain と複数プロファイルを混在させないことを推奨します。）
そこで、 trust_domain キーワードを廃止して、
（２）の機能だけを持った keep_domain キーワード（仮称）を導入し、
・アクセス制御の方法はプロファイルが管理
・ドメイン遷移の方法は initializer と keep_domain キーワードが管理
する方が扱いやすいのではないかと考えました。
ccs-patch-1.3-20061111.tar.gz に対するパッチを添付します。
patch -p1 で適用できます。
keep_domain キーワードの導入により、以下のようなメリットが得られます。
（Ａ）ドメイン数と消費メモリを減らすことができます。
（Ｂ）ログインしてからどんなコマンドをどんな順番で実行するか判らない場合でも強制モードを利用できます。
（Ｃ）強制アクセス制御が適用されるかどうかを判断しやすくなります。
（Ａ）については、例えば /etc/init.d/ ディレクトリ以下のスクリプトのように、
バイナリファイルであれば単一の実行可能ファイルで実現できる処理なのに
スクリプトである故に外部の実行可能ファイルを呼び出す必要があり
ドメイン遷移が発生してしまいます。しかし、（２）の機能だけを実装することで、
あたかも単一の実行可能ファイルであるかのようにドメイン遷移の発生を抑制できます。
SELinux の execute_no_trans みたいなものです。
例えば sshd の起動スクリプトの場合、現在は
* /etc/rc.d/init.d/sshd
/bin/rm
/bin/touch
/sbin/consoletype
/sbin/initlog
/usr/sbin/sshd ( -> 331 )
/usr/sbin/sshd ( -> 331 )
のようになっていますが、
keep_domain <kernel> /etc/rc.d/init.d/sshd
という指定を可能にすることで、
* /etc/rc.d/init.d/sshd
/usr/sbin/sshd ( -> 326 )
のようにドメインの数を減らせます。また、現在は
<kernel> /etc/rc.d/init.d/sshd
1 /bin/rm
1 /bin/touch
6 /dev/console
6 /dev/tty
4 /etc/mtab
4 /etc/nsswitch.conf
4 /etc/passwd
4 /etc/rc.d/init.d/functions
4 /etc/rc.d/init.d/sshd
4 /etc/sysconfig/i18n
4 /etc/sysconfig/init
1 /sbin/consoletype
1 /sbin/initlog
4 /usr/lib/gconv/EUC-JP.so
4 /usr/lib/gconv/libJIS.so
4 /usr/share/locale/ja/LC_MESSAGES/initscripts.mo
4 /var/run/sshd.pid
use_profile 0
<kernel> /etc/rc.d/init.d/sshd /bin/rm
allow_unlink /var/lock/subsys/sshd
use_profile 0
<kernel> /etc/rc.d/init.d/sshd /bin/touch
2 /var/lock/subsys/sshd
allow_create /var/lock/subsys/sshd
use_profile 0
<kernel> /etc/rc.d/init.d/sshd /sbin/consoletype
use_profile 0
<kernel> /etc/rc.d/init.d/sshd /sbin/initlog
2 /dev/null
4 /etc/initlog.conf
4 /usr/lib/gconv/EUC-JP.so
4 /usr/lib/gconv/libJIS.so
1 /usr/sbin/sshd
use_profile 0
のようになっているポリシーを
<kernel> /etc/rc.d/init.d/sshd
1 /bin/rm
1 /bin/touch
6 /dev/console
2 /dev/null
6 /dev/tty
4 /etc/initlog.conf
4 /etc/mtab
4 /etc/nsswitch.conf
4 /etc/passwd
4 /etc/rc.d/init.d/functions
4 /etc/rc.d/init.d/sshd
4 /etc/sysconfig/i18n
4 /etc/sysconfig/init
1 /sbin/consoletype
1 /sbin/initlog
4 /usr/lib/gconv/EUC-JP.so
4 /usr/lib/gconv/libJIS.so
1 /usr/sbin/sshd
4 /usr/share/locale/ja/LC_MESSAGES/initscripts.mo
2 /var/lock/subsys/sshd
4 /var/run/sshd.pid
allow_create /var/lock/subsys/sshd
allow_unlink /var/lock/subsys/sshd
use_profile 0
のように短くすることができ、消費メモリの削減にもなります。
（Ｂ）については、上記例をログインしてから許容する操作に置き換えると、
use_profile で強制モード用のプロファイルを割り当てることで
許可されたプログラムやファイルにしかアクセスさせないようにすることができます。
それでいながら、プログラムの実行順序は問いません。
どんなコマンドを実行するか判らないので無効モードにする必要がある現状を
許可されたコマンドの実行とファイルへのアクセスのみを認める強制モードで
置き換えることが可能になります。
（Ｃ）については、プロファイル番号がどうなっているかを確認するだけで済むため、
強制アクセス制御が適用されるかどうかを判断しやすくなります。
他にはどんなメリットやデメリットがあるかをまだ把握しきれていませんが、
多分メリットの方が大きいと思います。・・・というわけで、コメント募集です。
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: patch.txt
型: application/octet-stream
サイズ: 3023 バイト
説明: 無し
ダウンロード