TOMOYO

Fork

[Tomoyo-dev 1153] Re: プロファイルの指定方法の変更について

Hiroshi Shinji hiros****@gmail*****
2009年 8月 19日 (水) 14:02:03 JST

• 前の記事 [Tomoyo-dev 1152] Re: プロファイルの指定方法の変更について
• 次の記事 [Tomoyo-dev 1154] Re: プロファイルの指定方法の変更について
• 記事の並び順: [ 日付 ] [ スレッド ] [ 件名 ] [ 著者 ]

宍道です。

>> 具体的には、「とりあえず1.6.8までの機能が使えれば良いユーザ」が
>> 1.7に移行するためのマイグレーション手順で、プロファイラや
>> ポリシーの自動移行スクリプトのようなものが可能かどうか（提供
>> 予定があるかどうか）という観点です。
>>
> 基本的にポリシーは作り直しです。

今後1.6系は、1.7と並行してメンテナンスしていくんでしょうか？


>> > どう思いますか？
>>
>> ここの「どう」の中身が広くて答えにくいので、できれば
>> 選択肢から回答のような形にはなりませんでしょうか？
>>
> 選択肢１・・・変えない
＜中略＞
> 選択肢２・・・項目ごとに全ての情報を指定する。
＜中略＞
> 選択肢３・・・モードごとに全ての項目を指定する。
＜中略＞
> 選択肢４・・・選択肢１と選択肢３のミックス
＜以下略＞


個人的には、選択肢２が良いかと思います。
ただ、省略して書けるようにしてもらえるとうれしいです。
例えば基本は、

項目ｎ＝制御モード　必要　必要

ですが、

項目ｎ＝制御モード

とするとログをデフォルト（拒否=on、許可=off とか？）にするとか。
また全部省略した場合は、制御モード=disable ＆ ログ=off で。



では。


2009/08/18 17:29 に Tetsuo Handa<from-****@i-lov*****> さんは書きました:
> 　熊猫です。
>
> Toshiharu Harada さんは書きました：
>> On 8/18/2009 2:26 PM, Tetsuo Handa wrote:
>> > 熊猫です。
>> >
>> > TOMOYO 1.7 へ向けてそろそろ仕様を確定させようと思います。
>>
>> 最初に確認したいのですが、1.7とするのは1.6.8からポリシーの互換が
>> 失われる＝ポリシーの作り直しか移行が必要ということですか？
>> （後のほうまで読むとそのようですが念のため確認）
>>
> はい。今回は構文の統廃合を含むため、 1.6.x のポリシーを 1.7 で使うことは
> できません。また、構文が１対１対応ではないため移行支援ツールのようなものも
> 提供できません。
>
>> > 最大の特徴はガベージコレクタの搭載です。今まではシステムを再起動する以外に
>> > ポリシーを保持するために割り当てられたメモリを解放する手段がありませんでした
>> > が、 TOMOYO 1.7 ではポリシーが削除されると自動的に解放されるようになります。
>> > 解放できるようにするために TOMOYO 独自のメモリアロケータを用いてページ単位で
>> > 割り当てていたものを TOMOYO 独自のメモリアロケータを使わないで要素単位で
>> > 割り当てるようにしたため使用効率が落ちるのと、ポリシーの参照中にプロセスが
>> > クラッシュした場合には以後ガベージコレクタが機能しなくなってしまうという難点が
>> > ありますが、再起動せずにメモリを解放できる利点は大きいと思います。
>>
>> GCの導入については個人的に賛成なのですが、2系への提案が
>> 途中になっており、その結果（のコメントや指摘）を反映する
>> ようにしたほうが良くありませんか？
>>
>
> 1.7 は 2.2 で得られたコメントや指摘を 1.6 に反映したものです。
> 1.7 で path_group など 2.x に今後追加予定の構文に対しても GC を適用できることを
> 確認してから、 2.x に GC を追加します。
> 2.x を誰かにレビューしてもらうにしても、 2.x の構造の枝葉（どこで排他制御が
> 必要になるか）まで理解していることは期待できませんから、 GC の仕様に問題が
> 無いかどうかの確認を自前で行うことで、レビュアーに対して枝葉までの理解を
> 必要としないようにしているのです。（以前投稿した 2.2 用の GC パッチセットには
> 排他制御の漏れが残っていたことが 1.7 を開発する過程で判明しました。）
>
>> > 次の特徴は、スピンロックなどの排他機構の利用頻度を減らしたことによる
>> > スケーラビリティの向上です。今までは TOMOYO 独自でメモリ使用量をカウント
>> > していましたが、メモリリーク検出機能（ CONFIG_DEBUG_KMEMLEAK ）が
>> > カーネル 2.6.31 にマージされたことでもはや TOMOYO 独自でメモリリークを検出する
>> > 必要性は無くなったと判断し、メモリリークを検出するためのリストとそのリストを
>> > 操作するためのスピンロックが廃止されました。
>> > パス名を逆算する際に必要となる dcache_lock / vfsmount_lock スピンロックだけは
>> > 今後も避けられないので、１０２４ＣＰＵとかでもスケールするとは思っていませんが
>> > １６ＣＰＵぐらいまではスケールしてほしいなぁ。
>>
>> これは良いと思うのですが、2系についても提案できますか？
>>
> 2.2 ではすでにそのようになっています。
>
> ただし 2.2 では参照側もセマフォを必要としているので 1.7 ほどはスケールしない
> かもしれません。 2.x が SRCU に対応すれば 1.7 と同等かそれ以上のスケールを
> 期待できるようになるかと思います。 GC を導入するためのパッチセットの中で
> セマフォが SRCU に置き換えられるようになっています。（レビューしてくれる人が
> いるのであればセマフォを SRCU に置き換える部分だけを先に提案することも
> できます。）
>
>> > アクセスログについて項目単位で指定できるようにしました。これもパフォーマンス
>> > 向上のためのものです。今まではユーザ空間（ 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() で指定可能なモードを対象とするパス名と
>> > セットで制限することが可能になります。
>>
>> これは内部処理的な「強化」で、ユーザ（ポリシー管理者）的には
>> 影響しないと思って良いですか？
>>
> はい。これは構文の新規追加ですので、利用しないと判断した場合には
> 影響しません。 chmod / chown / chgrp に対するアクセス制御を有効にすると
>
> allow_chmod /dev/null 0666
>
> とか
>
> allow_chown @CHOWN_ALLOWED_PATH @CHOWN_IDS
>
> などの指定が可能になります。
>
>> > mknod() のチェックが強化されました。今まではデバイスファイルの作成時に
>> > デバイス番号はチェックしていませんでしたが、 TOMOYO 1.7 ではデバイス番号も
>> > チェックできるようにします。 allow_mkblock および allow_mkchar でデバイス番号も
>> > 制限できるようになったことで、ファイルシステム自体で名前とデバイス番号の
>> > 対応付けをチェックする必要性が無くなったので、 SYAORAN ファイルシステムは
>> > 廃止されました。
>>
>> 「デバイス番号も」とあるということは、これについては
>> 今までのポリシーは修正不要で使えると思って良いですか？
>>
> いいえ。これは構文の変更です。今までは
>
> allow_mkchar /dev/null
>
> だったものが
>
> allow_mkchar /dev/null 1 3
>
> のようになります。そのため、今までのポリシーを使うことができなくなります。
>
>> > 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 を
>> > 作成しやすくなります。
>>
>> これは意見ですが、ポリシーの作成はアプリケーションの
>> インストール後行うことにしてあまり問題ないように思います。
>>
> これはエンドユーザがポリシーを作成しない（ Android のような）環境向けに
> アプリケーションの作成者がポリシーを配布しやすくするための工夫です。
>
>> > 特定のローカルポート番号がポート番号に 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に移行するためのマイグレーション手順で、プロファイラや
>> ポリシーの自動移行スクリプトのようなものが可能かどうか（提供
>> 予定があるかどうか）という観点です。
>>
> 基本的にポリシーは作り直しです。
>
> allow_execute およびドメイン名は alias 構文が廃止されたことに伴い
> 指定すべきパス名が 1.6 までとは異なっている可能性があるので作り直す必要が
> あります。
>
> allow_mkchar および allow_mkblock はデバイス番号を指定する必要があるため
> 作り直す必要があります。
>
> allow_read/write などは構文の変化が無いため、そのまま使うことができます。
>
> exception_policy も alias 構文の代わりに aggregator 構文を追加するために
> 作り直しが必要になります。
>
>> > 今まではプログラムの実行可否（およびドメイン遷移）とファイル読み書きの可否を
>> > 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_mou!
>  nt
>>  }
>> > 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
>> >
>> > どう思いますか？
>>
>> ここの「どう」の中身が広くて答えにくいので、できれば
>> 選択肢から回答のような形にはなりませんでしょうか？
>>
> 選択肢１・・・変えない
>
> 「項目１個＝値１個」を項目の数だけ繰り返す。
> プロファイル番号１つにつき
>
> MAC_項目１＝制御モード
> MAC_項目２＝制御モード
> ・
> ・
> ・
> MAC_項目５８＝制御モード
> AUDIT_GRANT_項目１＝許可ログの指定
> AUDIT_GRANT_項目２＝許可ログの指定
> ・
> ・
> ・
> AUDIT_GRANT_項目５８＝許可ログの指定
> AUDIT_REJECT_項目１＝拒否ログの指定
> AUDIT_REJECT_項目２＝拒否ログの指定
> ・
> ・
> ・
> AUDIT_REJECT_項目５８＝拒否ログの指定
>
> のように１７４行を割り当てる。
>
> 選択肢２・・・項目ごとに全ての情報を指定する。
>
> 「項目１個＝制御モードの指定　許可ログの指定　拒否ログの指定」のようにする。
> プロファイル番号１つにつき
>
> 項目１＝制御モード　必要　不要
> 項目２＝制御モード　必要　必要
> ・
> ・
> ・
> 項目５８＝制御モード　不要　不要
>
> のように５８行を割り当てる。
>
> 選択肢３・・・モードごとに全ての項目を指定する。
>
> 「制御モード＝｛項目１　項目２・・・｝」のようにする。
> プロファイル番号１つにつき
>
> MAC_MODE_DISABLED={ 項目・・・ }
> MAC_MODE_LEARNING={ 項目・・・ }
> MAC_MODE_PERMISSIVE={ 項目・・・ }
> MAC_MODE_ENFORCING={ 項目・・・ }
> NO_AUDIT_GRANT_LOG={ 項目・・・ }
> NO_AUDIT_REJECT_LOG={ 項目・・・ }
>
> のように６行を割り当てる。
>
> 選択肢４・・・選択肢１と選択肢３のミックス
>
> 制御モードについては「項目＝モード」、アクセスログについては
> 「許可ログ＝｛ 項目・・・ ｝」「拒否ログ＝｛ 項目・・・ ｝」のようにする。
> プロファイル番号１つにつき
>
> MAC_項目１＝制御モード
> MAC_項目２＝制御モード
> ・
> ・
> ・
> MAC_項目５８＝制御モード
> NO_AUDIT_GRANT_LOG={ 項目・・・ }
> NO_AUDIT_REJECT_LOG={ 項目・・・ }
>
> のように６０行を割り当てる。
>
> ５８個の項目とは以下に列挙されているものです。
> 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
>
> _______________________________________________
> tomoyo-dev mailing list
> tomoy****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev
>



-- 
宍道 洋
hiros****@gmail*****
http://d.hatena.ne.jp/hshinji/

• 前の記事 [Tomoyo-dev 1152] Re: プロファイルの指定方法の変更について
• 次の記事 [Tomoyo-dev 1154] Re: プロファイルの指定方法の変更について
• 記事の並び順: [ 日付 ] [ スレッド ] [ 件名 ] [ 著者 ]