Tetsuo Handa
from-****@I-lov*****
2009年 8月 18日 (火) 14:26:37 JST
TOMOYO
Fork 熊猫です。
TOMOYO 1.7 へ向けてそろそろ仕様を確定させようと思います。
最大の特徴はガベージコレクタの搭載です。今まではシステムを再起動する以外に
ポリシーを保持するために割り当てられたメモリを解放する手段がありませんでした
が、 TOMOYO 1.7 ではポリシーが削除されると自動的に解放されるようになります。
解放できるようにするために TOMOYO 独自のメモリアロケータを用いてページ単位で
割り当てていたものを TOMOYO 独自のメモリアロケータを使わないで要素単位で
割り当てるようにしたため使用効率が落ちるのと、ポリシーの参照中にプロセスが
クラッシュした場合には以後ガベージコレクタが機能しなくなってしまうという難点が
ありますが、再起動せずにメモリを解放できる利点は大きいと思います。
次の特徴は、スピンロックなどの排他機構の利用頻度を減らしたことによる
スケーラビリティの向上です。今までは TOMOYO 独自でメモリ使用量をカウント
していましたが、メモリリーク検出機能（ CONFIG_DEBUG_KMEMLEAK ）が
カーネル 2.6.31 にマージされたことでもはや TOMOYO 独自でメモリリークを検出する
必要性は無くなったと判断し、メモリリークを検出するためのリストとそのリストを
操作するためのスピンロックが廃止されました。
パス名を逆算する際に必要となる dcache_lock / vfsmount_lock スピンロックだけは
今後も避けられないので、１０２４ＣＰＵとかでもスケールするとは思っていませんが
１６ＣＰＵぐらいまではスケールしてほしいなぁ。
アクセスログについて項目単位で指定できるようにしました。これもパフォーマンス
向上のためのものです。今まではユーザ空間（ ccs-auditd 側）でフィルタリング
すればよいと思っていましたが、アクセスログのリストに対する追加／削除の際に
必要となるスピンロックの処理は熊猫が思っているよりも重いらしいということが
判明したため、（例えばＷｅｂサーバで allow_network の許可ログは不要だけど
allow_read の許可ログは欲しいという場合のように）アクセスログを取得する
つもりのない項目については最初からアクセスログのリストへの追加を行わない
ようにしました。
chown() / chgrp() / chmod() のチェックが強化されました。
今までは chown() / chgrp() / chmod() の可否は SYS_CHOWN および SYS_CHMOD
ケイパビリティを用いて制限していましたが、 UnionFS のようにファイルシステム
内部で chown() / chgrp() / chmod() を呼び出すものがあり、ユーザ空間の
プログラムにとっては不要な場合でも SYS_CHOWN および SYS_CHMOD 権限を
与えなければいけないケースがありました。 TOMOYO 1.7 では新たにフックを
挿入することで、ユーザ空間のプログラムからの chown() / chgrp() / chmod()
要求とファイルシステム内部からの要求とを区別できるようにし、さらに chown() /
chgrp() で指定可能なＩＤや chmod() で指定可能なモードを対象とするパス名と
セットで制限することが可能になります。
mknod() のチェックが強化されました。今まではデバイスファイルの作成時に
デバイス番号はチェックしていませんでしたが、 TOMOYO 1.7 ではデバイス番号も
チェックできるようにします。 allow_mkblock および allow_mkchar でデバイス番号も
制限できるようになったことで、ファイルシステム自体で名前とデバイス番号の
対応付けをチェックする必要性が無くなったので、 SYAORAN ファイルシステムは
廃止されました。
system_policy.conf が廃止されました。
system_policy.conf で使われていた構文の内、 deny_autobind 構文は
exception_policy.conf へ移動、それ以外の構文は domain_policy.conf へ
移動します。これにより、ドメイン単位で名前空間の変更に対する操作を
制限できるようになりました。
alias 構文および allow_argv0 構文が廃止されました。
今まではシンボリックリンクの実行は alias 構文で明示されない限り
シンボリックリンクを解決したパス名の実行許可をチェックしていましたが、
TOMOYO 1.7 ではシンボリックリンクを解決する前のパス名の実行許可を
チェックするようにし、必要であれば allow_execute 構文の if 節の
exec.realpath および exec.argv[0] をチェックするようになりました。
数値をグループ化する number_group 構文が追加されました。
Android ではアプリケーション毎に異なるＵＩＤが割り当てられますが、
インストール時までＵＩＤが不明なため、
allow_read /data/data/app1/\* if task.uid=10000-10001
のように数値での指定しかサポートしていないと
事前に domain_policy.conf を作成する際に不便です。
そこで、 exception_policy.conf で
number_group APP1_DATA_READERS 10000
number_group APP1_DATA_READERS 10001
のように指定することで
allow_read /data/data/app1/\* if task.uid=@APP1_DATA_READERS
のように分離することが可能になり、事前に domain_policy.conf を
作成しやすくなります。
特定のローカルポート番号がポート番号に 0 を指定した bind() によって
使われてしまうのを防ぐ RESTRICT_AUTOBIND のモード指定が無くなります。
RESTRICT_AUTOBIND はブラックリスト方式のため、学習モードや確認モードが
存在しません。 disabled か enabled かしか無いわけですが、デフォルトでは
何も制限しません。プロファイル単位で disabled か enabled かを指定できる
必要性は無いでしょうから、常に enabled にしました。これにより、プロファイル
から RESTRICT_AUTOBIND が消滅します。（話が脱線しますが最近は portreserve
というユーティリティが登場しているようです。特定のローカルポート番号が無断で
使われてしまうのを予防するという発想は SAKURA Linux と同じですね。）
プロファイルの指定方法が変わります。
今までは MAC_FOR_FILE や MAC_FOR_NETWORK のように「 MAC_FOR_種類 」という
分類をしていましたが、これを種類単位ではなく項目単位で指定するようにします。
MAC_FOR_FILE にはパス名に対する以下の操作だけが含まれていました。
open(O_RDONLY/O_WRONLY/O_RDWR)
execve()
creat()
unlink()
mkdir()
rmdir()
mkfifo()
mksock()
mkblock()
mkchar()
truncate()
symlink()
rewrite
link()
rename()
でも、 MAC_FOR_IOCTL に含まれている ioctl() も、 RESTRICT_〜 に含まれている
mount() / umount() / chroot() / pivot_root() も、今回追加される chmod() /
chown() / chgrp() もパス名に対する操作です。（つまり env network signal および
ケイパビリティ以外は全てパス名に対する操作です。）なぜ ioctl() / mount() /
umount() / chroot() / pivot_root() / chmod() / chown() / chgrp() が
MAC_FOR_FILE に含まれていないのかというと、「マイナーバージョンアップの中で
MAC_FOR_FILE に追加すると（チェック箇所が増えることで）アクセスが拒否される
可能性が生じるため追加できなかった」からです。
今回 TOMOYO 1.7 では TOMOYO 1.6 との互換性が無いことがはっきりしているので、
この機会に MAC_FOR_FILE に追加するというのも考えられますが、 MAC_FOR_FILE を
廃止した方が以下に述べるようにより柔軟な運用が可能になります。
今まではプログラムの実行可否（およびドメイン遷移）とファイル読み書きの可否を
MAC_FOR_FILE で指定していたため、ドメイン遷移の設計とファイルアクセスの可否を
同時に強制モードにする必要がありました。
プログラムの実行可否（およびドメイン遷移）だけを先に強制モードにできるように
することで、プログラムの実行可否（およびドメイン遷移）のみを先に確定（強制
モード）してから他のアクセス許可を追加（学習モード）していくことが可能に
なります。また、プログラムの実行の可否（およびドメイン遷移）だけを制御したい
という用途でも使えるようになります。
他にもあるような気がしますがとりあえずここまで。
今回の投稿の目的は、プロファイルの指定方法についてご意見募集です。
今までは
項目１＝制御モード
項目２＝制御モード
・
・
・
項目Ｎ＝制御モード
のように１行に１つの値を指定していました。
しかし、指定可能な項目（現在５８項目）が増えると縦方向に伸びてしまいます。
今回、項目毎にアクセスログを生成するかどうか指定できるようにしたことにより、
AUDIT_GRANT::項目１＝enabled または diabled
AUDIT_GRANT::項目２＝enabled または diabled
・
・
・
AUDIT_GRANT::項目Ｎ＝enabled または diabled
AUDIT_REJECT::項目１＝enabled または diabled
AUDIT_REJECT::項目２＝enabled または diabled
・
・
・
AUDIT_REJECT::項目Ｎ＝enabled または diabled
のように縦方向にもっと伸びてしまう要因が加わりました。
そこで、例えば
項目１＝制御モード audit_grant
項目２＝制御モード audit_reject
・
・
・
項目Ｎ＝制御モード audit_reject
のように１項目に複数の値を指定できるようにするか、あるいは
MAC_MODE_ENFORCING={ 項目１ }
MAC_MODE_PERMISSIVE={ 項目２ 項目５}
MAC_MODE_LEARNING={ 項目６ 項目Ｎ }
MAC_MODE_DISABLED={ 項目３ 項目４ }
NO_AUDIT_GRANT_LOG={ 項目６ 項目Ｎ }
NO_AUDIT_REJECT_LOG={ 項目１ }
のようにモード毎に全ての値を指定できるようにすることで
縦方向への伸びを抑制した方が良いのではないかと思っています。
（ revision 2918 では以下のように「モード毎に全ての値を指定」する方法を
採っています。）
0-COMMENT=-----Disabled Mode-----
0-MAC_MODE_DISABLED={ execute open create unlink mkdir rmdir mkfifo mksock truncate symlink rewrite mkblock mkchar link rename chmod chown chgrp ioctl chroot mount umount pivot_root env network signal capability::inet_tcp_create capability::inet_tcp_listen capability::inet_tcp_connect capability::use_inet_udp capability::use_inet_ip capability::use_route capability::use_packet capability::SYS_MOUNT capability::SYS_UMOUNT capability::SYS_REBOOT capability::SYS_CHROOT capability::SYS_KILL capability::SYS_VHANGUP capability::SYS_TIME capability::SYS_NICE capability::SYS_SETHOSTNAME capability::use_kernel_module capability::create_fifo capability::create_block_dev capability::create_char_dev capability::create_unix_socket capability::SYS_LINK capability::SYS_SYMLINK capability::SYS_RENAME capability::SYS_UNLINK capability::SYS_CHMOD capability::SYS_CHOWN capability::SYS_IOCTL capability::SYS_KEXEC_LOAD capability::SYS_PIVOT_ROOT capability::SYS_PTRACE capability::conceal_mount }
0-MAC_MODE_LEARNING={ }
0-MAC_MODE_PERMISSIVE={ }
0-MAC_MODE_ENFORCING={ }
0-NO_AUDIT_GRANT_LOG={ }
0-NO_AUDIT_REJECT_LOG={ }
0-AUTOLEARN_EXEC_REALPATH=enabled
0-AUTOLEARN_EXEC_ARGV0=enabled
0-MAX_ACCEPT_ENTRY=2048
0-MAX_GRANT_LOG=1024
0-MAX_REJECT_LOG=1024
0-PRINT_VIOLATION=enabled
どう思いますか？