Toshiharu Harada
harad****@nttda*****
2009年 8月 18日 (火) 15:18:11 JST
TOMOYO
ForkOn 8/18/2009 2:26 PM, Tetsuo Handa wrote:
> 熊猫です。
>
> TOMOYO 1.7 へ向けてそろそろ仕様を確定させようと思います。
最初に確認したいのですが、1.7とするのは1.6.8からポリシーの互換が
失われる＝ポリシーの作り直しか移行が必要ということですか？
（後のほうまで読むとそのようですが念のため確認）
> 最大の特徴はガベージコレクタの搭載です。今まではシステムを再起動する以外に
> ポリシーを保持するために割り当てられたメモリを解放する手段がありませんでした
> が、 TOMOYO 1.7 ではポリシーが削除されると自動的に解放されるようになります。
> 解放できるようにするために TOMOYO 独自のメモリアロケータを用いてページ単位で
> 割り当てていたものを TOMOYO 独自のメモリアロケータを使わないで要素単位で
> 割り当てるようにしたため使用効率が落ちるのと、ポリシーの参照中にプロセスが
> クラッシュした場合には以後ガベージコレクタが機能しなくなってしまうという難点が
> ありますが、再起動せずにメモリを解放できる利点は大きいと思います。
GCの導入については個人的に賛成なのですが、2系への提案が
途中になっており、その結果（のコメントや指摘）を反映する
ようにしたほうが良くありませんか？
> 次の特徴は、スピンロックなどの排他機構の利用頻度を減らしたことによる
> スケーラビリティの向上です。今までは TOMOYO 独自でメモリ使用量をカウント
> していましたが、メモリリーク検出機能（ CONFIG_DEBUG_KMEMLEAK ）が
> カーネル 2.6.31 にマージされたことでもはや TOMOYO 独自でメモリリークを検出する
> 必要性は無くなったと判断し、メモリリークを検出するためのリストとそのリストを
> 操作するためのスピンロックが廃止されました。
> パス名を逆算する際に必要となる dcache_lock / vfsmount_lock スピンロックだけは
> 今後も避けられないので、１０２４ＣＰＵとかでもスケールするとは思っていませんが
> １６ＣＰＵぐらいまではスケールしてほしいなぁ。
これは良いと思うのですが、2系についても提案できますか？
> アクセスログについて項目単位で指定できるようにしました。これもパフォーマンス
> 向上のためのものです。今まではユーザ空間（ 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 へ
> 移動します。これにより、ドメイン単位で名前空間の変更に対する操作を
> 制限できるようになりました。
1.6.8からの移行の流れとしてはどのようになるのでしょうか？
（「移動します」とあるのは、場所が変わるから自分で移せということなのか、
起動時にやってくれるということなのか）
> 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 を
> 廃止した方が以下に述べるようにより柔軟な運用が可能になります。
ここまで読んで、ポリシーの互換性がないことがわかったのですが、
ユーザサイドとしての対応について説明してもらえませんか？
具体的には、「とりあえず1.6.8までの機能が使えれば良いユーザ」が
1.7に移行するためのマイグレーション手順で、プロファイラや
ポリシーの自動移行スクリプトのようなものが可能かどうか（提供
予定があるかどうか）という観点です。
> 今まではプログラムの実行可否（およびドメイン遷移）とファイル読み書きの可否を
> 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
>
> どう思いますか？
ここの「どう」の中身が広くて答えにくいので、できれば
選択肢から回答のような形にはなりませんでしょうか？
--
原田季栄 (Toshiharu Harada)
harad****@nttda*****