From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Tue Aug 18 14:26:37 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 18 Aug 2009 14:26:37 +0900 Subject: [Tomoyo-dev 1150] =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlE5OSRLGyhC?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= Message-ID: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> 　熊猫です。 　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 どう思いますか？ From haradats ＠ nttdata.co.jp Tue Aug 18 15:18:11 2009 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Tue, 18 Aug 2009 15:18:11 +0900 Subject: [Tomoyo-dev 1151] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> Message-ID: <4A8A47A3.4070002@nttdata.co.jp> On 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) haradats at nttdata.co.jp From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Tue Aug 18 17:29:48 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 18 Aug 2009 17:29:48 +0900 Subject: [Tomoyo-dev 1152] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <4A8A47A3.4070002@nttdata.co.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <4A8A47A3.4070002@nttdata.co.jp> Message-ID: <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> 　熊猫です。 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 From hiroshi.shinji ＠ gmail.com Wed Aug 19 14:02:03 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Wed, 19 Aug 2009 14:02:03 +0900 Subject: [Tomoyo-dev 1153] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <4A8A47A3.4070002@nttdata.co.jp> <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> Message-ID: 宍道です。 >> 具体的には、「とりあえず1.6.8までの機能が使えれば良いユーザ」が >> 1.7に移行するためのマイグレーション手順で、プロファイラや >> ポリシーの自動移行スクリプトのようなものが可能かどうか（提供 >> 予定があるかどうか）という観点です。 >> > 基本的にポリシーは作り直しです。 今後1.6系は、1.7と並行してメンテナンスしていくんでしょうか？ >> > どう思いますか？ >> >> ここの「どう」の中身が広くて答えにくいので、できれば >> 選択肢から回答のような形にはなりませんでしょうか？ >> > 選択肢１・・・変えない ＜中略＞ > 選択肢２・・・項目ごとに全ての情報を指定する。 ＜中略＞ > 選択肢３・・・モードごとに全ての項目を指定する。 ＜中略＞ > 選択肢４・・・選択肢１と選択肢３のミックス ＜以下略＞ 個人的には、選択肢２が良いかと思います。 ただ、省略して書けるようにしてもらえるとうれしいです。 例えば基本は、 項目ｎ＝制御モード　必要　必要 ですが、 項目ｎ＝制御モード とするとログをデフォルト（拒否=on、許可=off とか？）にするとか。 また全部省略した場合は、制御モード=disable ＆ ログ=off で。 では。 2009/08/18 17:29 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > 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 > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Aug 19 14:28:40 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 19 Aug 2009 14:28:40 +0900 Subject: [Tomoyo-dev 1154] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <4A8A47A3.4070002@nttdata.co.jp> <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> Message-ID: <200908190528.n7J5Sfmq049652@www262.sakura.ne.jp> 　熊猫です。 Hiroshi Shinji さんは書きました： > 今後1.6系は、1.7と並行してメンテナンスしていくんでしょうか？ もちろんです。 1.6 系はバグフィックス以外行わないようにします。 > > 選択肢１・・・変えない > ＜中略＞ > > 選択肢２・・・項目ごとに全ての情報を指定する。 > ＜中略＞ > > 選択肢３・・・モードごとに全ての項目を指定する。 > ＜中略＞ > > 選択肢４・・・選択肢１と選択肢３のミックス > ＜以下略＞ > > > 個人的には、選択肢２が良いかと思います。 > ただ、省略して書けるようにしてもらえるとうれしいです。 > 例えば基本は、 > > 項目ｎ＝制御モード　必要　必要 > > ですが、 > > 項目ｎ＝制御モード > > とするとログをデフォルト（拒否=on、許可=off とか？）にするとか。 > また全部省略した場合は、制御モード=disable ＆ ログ=off で。 制御モードのデフォルトは「 disabled 」、ログのデフォルトは「出力する」です。 ですから、選択肢３や選択肢４では「出力しない」項目だけを NO_AUDIT_GRANT_LOG= および NO_AUDIT_REJECT_LOG= に指定してもらうことにより、省略可能な指定が できます。（だから選択肢２より便利だと熊猫は思います。） 現時点で、デムパゆんゆんさんが選択肢４、宍道さんが選択肢２です。 他の方はどうですか？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Aug 19 21:06:41 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 19 Aug 2009 21:06:41 +0900 Subject: [Tomoyo-dev 1155] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <4A8A47A3.4070002@nttdata.co.jp> <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> Message-ID: <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> 　熊猫です。 Hiroshi Shinji さんは書きました： > 個人的には、選択肢２が良いかと思います。 revision 2925 では選択肢２の状態です。 以下のような指定になります。 0-AUTOLEARN_EXEC_ARGV0=enabled 0-AUTOLEARN_EXEC_REALPATH=enabled 0-COMMENT=-----Disabled Mode----- 0-MAC::capability::SYS_CHMOD=disabled 0-MAC::capability::SYS_CHOWN=disabled 0-MAC::capability::SYS_CHROOT=disabled 0-MAC::capability::SYS_IOCTL=disabled 0-MAC::capability::SYS_KEXEC_LOAD=disabled 0-MAC::capability::SYS_KILL=disabled 0-MAC::capability::SYS_LINK=disabled 0-MAC::capability::SYS_MOUNT=disabled 0-MAC::capability::SYS_NICE=disabled 0-MAC::capability::SYS_PIVOT_ROOT=disabled 0-MAC::capability::SYS_PTRACE=disabled 0-MAC::capability::SYS_REBOOT=disabled 0-MAC::capability::SYS_RENAME=disabled 0-MAC::capability::SYS_SETHOSTNAME=disabled 0-MAC::capability::SYS_SYMLINK=disabled 0-MAC::capability::SYS_TIME=disabled 0-MAC::capability::SYS_UMOUNT=disabled 0-MAC::capability::SYS_UNLINK=disabled 0-MAC::capability::SYS_VHANGUP=disabled 0-MAC::capability::conceal_mount=disabled 0-MAC::capability::create_block_dev=disabled 0-MAC::capability::create_char_dev=disabled 0-MAC::capability::create_fifo=disabled 0-MAC::capability::create_unix_socket=disabled 0-MAC::capability::inet_tcp_connect=disabled 0-MAC::capability::inet_tcp_create=disabled 0-MAC::capability::inet_tcp_listen=disabled 0-MAC::capability::use_inet_ip=disabled 0-MAC::capability::use_inet_udp=disabled 0-MAC::capability::use_kernel_module=disabled 0-MAC::capability::use_packet=disabled 0-MAC::capability::use_route=disabled 0-MAC::chgrp=disabled 0-MAC::chmod=disabled 0-MAC::chown=disabled 0-MAC::chroot=disabled 0-MAC::create=disabled 0-MAC::env=disabled no_grant_log no_reject_log 0-MAC::execute=learning no_reject_log 0-MAC::ioctl=disabled 0-MAC::link=disabled 0-MAC::mkblock=disabled 0-MAC::mkchar=disabled 0-MAC::mkdir=disabled 0-MAC::mkfifo=disabled 0-MAC::mksock=disabled 0-MAC::mount=disabled 0-MAC::network=disabled 0-MAC::open=learning no_grant_log 0-MAC::pivot_root=disabled 0-MAC::rename=disabled 0-MAC::rewrite=disabled 0-MAC::rmdir=disabled 0-MAC::signal=disabled 0-MAC::symlink=disabled 0-MAC::truncate=disabled 0-MAC::umount=disabled 0-MAC::unlink=disabled 0-MAX_ACCEPT_ENTRY=2048 0-MAX_GRANT_LOG=1024 0-MAX_REJECT_LOG=1024 0-PRINT_VIOLATION=enabled 0-SLEEP_PERIOD=0 ところで、ケイパビリティの名前ですが、 SYS_PIVOT_ROOT とか SYS_PTRACE のようなシステムコールの名前よりも swap-root-directory とか trace-process のような説明的な名前にしたほうが （システムコールの名前を知らないユーザにとって）親切なのではないかと思いました。 （システムコールの名前を知っているユーザにとっては不便になるかもしれませんが） 以下のような感じで置換したほうが良いでしょうか？ sed -i -e 's/inet_tcp_create/create-inet-tcp-socket/g' -e 's/inet_tcp_listen/listen-inet-tcp-socket/g' -e 's/inet_tcp_connect/connect-inet-tcp-socket/g' -e 's/use_inet_udp/use-inet-udp-socket/g' -e 's/use_inet_ip/use-inet-ip-socket/g' -e 's/use_route/use-route-socket/g' -e 's/use_packet/use-packet-socket/g' -e 's/SYS_MOUNT/mount-filesystem/g' -e 's/SYS_UMOUNT/unmount-filesystem/g' -e 's/SYS_REBOOT/reboot-system/g' -e 's/SYS_CHROOT/change-root-directory/g' -e 's/SYS_KILL/kill-process/g' -e 's/SYS_VHANGUP/simulate-hangup/g' -e 's/SYS_TIME/change-time/g' -e 's/SYS_NICE/change-priority/g' -e 's/SYS_SETHOSTNAME/change-hostname/g' -e 's/use_kernel_module/use-kernel-module/g' -e 's/create_fifo/create-fifo/g' -e 's/create_block_dev/create-block-device/g' -e 's/create_char_dev/create-char-device/g' -e 's/create_unix_socket/create-unix-socket/g' -e 's/SYS_LINK/create-link/g' -e 's/SYS_SYMLINK/create-symlink/g' -e 's/SYS_RENAME/use-rename/g' -e 's/SYS_UNLINK/use-unlink/g' -e 's/SYS_CHMOD/use-chmod/g' -e 's/SYS_CHOWN/use-chown/g' -e 's/SYS_IOCTL/use-ioctl/g' -e 's/SYS_KEXEC_LOAD/load-kernel/g' -e 's/SYS_PIVOT_ROOT/swap-root-directory/g' -e 's/SYS_PTRACE/trace-process/g' -e 's/conceal_mount/overlap-mount/g' From hiroshi.shinji ＠ gmail.com Thu Aug 20 11:15:14 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Thu, 20 Aug 2009 11:15:14 +0900 Subject: [Tomoyo-dev 1156] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <4A8A47A3.4070002@nttdata.co.jp> <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> Message-ID: 宍道です。 > 0-MAC::capability::SYS_CHMOD=disabled > 0-MAC::capability::SYS_CHOWN=disabled > 0-MAC::capability::SYS_CHROOT=disabled ＜中略＞ > 0-MAC::capability::use_kernel_module=disabled > 0-MAC::capability::use_packet=disabled > 0-MAC::capability::use_route=disabled これらcapabilityについて、まとめられませんか？ たとえば、 0-MAC::capability=disabled などとしてcapability関連すべて同じ設定にし、必要があればその後 0-MAC::capability::SYS_KILL=learning などと上書きできればありがたいです。 > ところで、ケイパビリティの名前ですが、 > SYS_PIVOT_ROOT とか SYS_PTRACE のようなシステムコールの名前よりも > swap-root-directory とか trace-process のような説明的な名前にしたほうが > （システムコールの名前を知らないユーザにとって）親切なのではないかと思いました。 > （システムコールの名前を知っているユーザにとっては不便になるかもしれませんが） > 以下のような感じで置換したほうが良いでしょうか？ どちらでもいいですが... （どちらかというと、私は変えなくても良いかな、と思っております...） 2009/08/19 21:06 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > Hiroshi Shinji さんは書きました： >> 個人的には、選択肢２が良いかと思います。 > revision 2925 では選択肢２の状態です。 > 以下のような指定になります。 > > 0-AUTOLEARN_EXEC_ARGV0=enabled > 0-AUTOLEARN_EXEC_REALPATH=enabled > 0-COMMENT=-----Disabled Mode----- > 0-MAC::capability::SYS_CHMOD=disabled > 0-MAC::capability::SYS_CHOWN=disabled > 0-MAC::capability::SYS_CHROOT=disabled > 0-MAC::capability::SYS_IOCTL=disabled > 0-MAC::capability::SYS_KEXEC_LOAD=disabled > 0-MAC::capability::SYS_KILL=disabled > 0-MAC::capability::SYS_LINK=disabled > 0-MAC::capability::SYS_MOUNT=disabled > 0-MAC::capability::SYS_NICE=disabled > 0-MAC::capability::SYS_PIVOT_ROOT=disabled > 0-MAC::capability::SYS_PTRACE=disabled > 0-MAC::capability::SYS_REBOOT=disabled > 0-MAC::capability::SYS_RENAME=disabled > 0-MAC::capability::SYS_SETHOSTNAME=disabled > 0-MAC::capability::SYS_SYMLINK=disabled > 0-MAC::capability::SYS_TIME=disabled > 0-MAC::capability::SYS_UMOUNT=disabled > 0-MAC::capability::SYS_UNLINK=disabled > 0-MAC::capability::SYS_VHANGUP=disabled > 0-MAC::capability::conceal_mount=disabled > 0-MAC::capability::create_block_dev=disabled > 0-MAC::capability::create_char_dev=disabled > 0-MAC::capability::create_fifo=disabled > 0-MAC::capability::create_unix_socket=disabled > 0-MAC::capability::inet_tcp_connect=disabled > 0-MAC::capability::inet_tcp_create=disabled > 0-MAC::capability::inet_tcp_listen=disabled > 0-MAC::capability::use_inet_ip=disabled > 0-MAC::capability::use_inet_udp=disabled > 0-MAC::capability::use_kernel_module=disabled > 0-MAC::capability::use_packet=disabled > 0-MAC::capability::use_route=disabled > 0-MAC::chgrp=disabled > 0-MAC::chmod=disabled > 0-MAC::chown=disabled > 0-MAC::chroot=disabled > 0-MAC::create=disabled > 0-MAC::env=disabled no_grant_log no_reject_log > 0-MAC::execute=learning no_reject_log > 0-MAC::ioctl=disabled > 0-MAC::link=disabled > 0-MAC::mkblock=disabled > 0-MAC::mkchar=disabled > 0-MAC::mkdir=disabled > 0-MAC::mkfifo=disabled > 0-MAC::mksock=disabled > 0-MAC::mount=disabled > 0-MAC::network=disabled > 0-MAC::open=learning no_grant_log > 0-MAC::pivot_root=disabled > 0-MAC::rename=disabled > 0-MAC::rewrite=disabled > 0-MAC::rmdir=disabled > 0-MAC::signal=disabled > 0-MAC::symlink=disabled > 0-MAC::truncate=disabled > 0-MAC::umount=disabled > 0-MAC::unlink=disabled > 0-MAX_ACCEPT_ENTRY=2048 > 0-MAX_GRANT_LOG=1024 > 0-MAX_REJECT_LOG=1024 > 0-PRINT_VIOLATION=enabled > 0-SLEEP_PERIOD=0 > > > > ところで、ケイパビリティの名前ですが、 > SYS_PIVOT_ROOT とか SYS_PTRACE のようなシステムコールの名前よりも > swap-root-directory とか trace-process のような説明的な名前にしたほうが > （システムコールの名前を知らないユーザにとって）親切なのではないかと思いました。 > （システムコールの名前を知っているユーザにとっては不便になるかもしれませんが） > 以下のような感じで置換したほうが良いでしょうか？ > > sed -i > -e 's/inet_tcp_create/create-inet-tcp-socket/g' > -e 's/inet_tcp_listen/listen-inet-tcp-socket/g' > -e 's/inet_tcp_connect/connect-inet-tcp-socket/g' > -e 's/use_inet_udp/use-inet-udp-socket/g' > -e 's/use_inet_ip/use-inet-ip-socket/g' > -e 's/use_route/use-route-socket/g' > -e 's/use_packet/use-packet-socket/g' > -e 's/SYS_MOUNT/mount-filesystem/g' > -e 's/SYS_UMOUNT/unmount-filesystem/g' > -e 's/SYS_REBOOT/reboot-system/g' > -e 's/SYS_CHROOT/change-root-directory/g' > -e 's/SYS_KILL/kill-process/g' > -e 's/SYS_VHANGUP/simulate-hangup/g' > -e 's/SYS_TIME/change-time/g' > -e 's/SYS_NICE/change-priority/g' > -e 's/SYS_SETHOSTNAME/change-hostname/g' > -e 's/use_kernel_module/use-kernel-module/g' > -e 's/create_fifo/create-fifo/g' > -e 's/create_block_dev/create-block-device/g' > -e 's/create_char_dev/create-char-device/g' > -e 's/create_unix_socket/create-unix-socket/g' > -e 's/SYS_LINK/create-link/g' > -e 's/SYS_SYMLINK/create-symlink/g' > -e 's/SYS_RENAME/use-rename/g' > -e 's/SYS_UNLINK/use-unlink/g' > -e 's/SYS_CHMOD/use-chmod/g' > -e 's/SYS_CHOWN/use-chown/g' > -e 's/SYS_IOCTL/use-ioctl/g' > -e 's/SYS_KEXEC_LOAD/load-kernel/g' > -e 's/SYS_PIVOT_ROOT/swap-root-directory/g' > -e 's/SYS_PTRACE/trace-process/g' > -e 's/conceal_mount/overlap-mount/g' > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From haradats ＠ nttdata.co.jp Thu Aug 20 11:27:12 2009 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Thu, 20 Aug 2009 11:27:12 +0900 Subject: [Tomoyo-dev 1157] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <4A8A47A3.4070002@nttdata.co.jp> <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> Message-ID: <4A8CB480.50207@nttdata.co.jp> On 8/20/2009 11:15 AM, Hiroshi Shinji wrote: >> ところで、ケイパビリティの名前ですが、 >> SYS_PIVOT_ROOT とか SYS_PTRACE のようなシステムコールの名前よりも >> swap-root-directory とか trace-process のような説明的な名前にしたほうが >> （システムコールの名前を知らないユーザにとって）親切なのではないかと思いました。 >> （システムコールの名前を知っているユーザにとっては不便になるかもしれませんが） >> 以下のような感じで置換したほうが良いでしょうか？ > > どちらでもいいですが... > （どちらかというと、私は変えなくても良いかな、と思っております...） 私も宍道さんに賛成です。 「説明としてわかりやすいかどうか」は主観に依存しますが、 システムコールの名前であれば誰にとっても同じで、確認も 容易です。また、原則として変える必要のないものは 極力変えないほうが良いとも思っています。 -- 原田季栄 (Toshiharu Harada) haradats at nttdata.co.jp From haradats ＠ nttdata.co.jp Thu Aug 20 11:32:47 2009 From: haradats ＠ nttdata.co.jp (Toshiharu Harada) Date: Thu, 20 Aug 2009 11:32:47 +0900 Subject: [Tomoyo-dev 1158] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> Message-ID: <4A8CB5CF.8010606@nttdata.co.jp> On 8/18/2009 2:26 PM, Tetsuo Handa wrote: > 　熊猫です。 > > 　TOMOYO 1.7 へ向けてそろそろ仕様を確定させようと思います。 半田さんが予定している1.7の仕様について、内容としては 以下に分類できると理解しています。 ・実装の修正（改善） 　　ガベージコレクタ・・・メインラインに提案中（近日再提案予定） 　　スピンロック・・・メインライン(2.2)に反映済み ・仕様変更、機能強化 ・プロファイルの定義仕様 提案ですが、ユーザ側（ポリシーの仕様）に影響しない内容を まず1.6.9としてリリースするわけにはいきませんか？ > 　最大の特徴はガベージコレクタの搭載です。今まではシステムを再起動する以外に > ポリシーを保持するために割り当てられたメモリを解放する手段がありませんでした > が、 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 > > どう思いますか？ > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev at lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 原田季栄 (Toshiharu Harada) haradats at nttdata.co.jp From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 20 12:01:32 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 20 Aug 2009 12:01:32 +0900 Subject: [Tomoyo-dev 1159] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <4A8A47A3.4070002@nttdata.co.jp> <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> Message-ID: <200908200301.n7K31W40021056@www262.sakura.ne.jp> 　熊猫です。 Hiroshi Shinji さんは書きました： > > 0-MAC::capability::SYS_CHMOD=disabled > > 0-MAC::capability::SYS_CHOWN=disabled > > 0-MAC::capability::SYS_CHROOT=disabled > ＜中略＞ > > 0-MAC::capability::use_kernel_module=disabled > > 0-MAC::capability::use_packet=disabled > > 0-MAC::capability::use_route=disabled > > これらcapabilityについて、まとめられませんか？ > たとえば、 > > 0-MAC::capability=disabled > > などとしてcapability関連すべて同じ設定にし、必要があればその後 > > 0-MAC::capability::SYS_KILL=learning > > などと上書きできればありがたいです。 纏めることは可能ですが、そうするとケイパビリティを追加するのが難しくなります。 1.6.5 → 1.6.7 の時、 MAC_FOR_FILE に ioctl を追加すると ioctl の追加前に 作成された domain_policy で MAC_FOR_FILE=enforcing にすると ioctl でエラーに なるため、 MAC_FOR_IOCTL として追加したという出来事と同じことが今後 1.7 でも 起こります。 MAC_FOR_FILE を execute open mkdir などに分割したのは、 1.7 の間に ファイルに対するアクセス制御機能が追加された場合に対応できるようにするため という理由もあります。 ですから、 3-MAC::capability=enforcing というデフォルト指定が行われた場合に どのケイパビリティを enforcing にするかを判断できるようにする方法が必要です。 例えば「プロファイル番号-項目=値」という設定以外に 「 PROFILE_VERSION=20090903 」みたいな形で指定するとか。 あるいは、「 SUPPORTED_CAPABILITIES={ ケイパビリティのリスト } 」みたいな形で 指定するとか。 From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 20 12:07:24 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 20 Aug 2009 12:07:24 +0900 Subject: [Tomoyo-dev 1160] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <4A8CB5CF.8010606@nttdata.co.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <4A8CB5CF.8010606@nttdata.co.jp> Message-ID: <200908200307.n7K37Opc022709@www262.sakura.ne.jp> 　熊猫です。 Toshiharu Harada さんは書きました： > 提案ですが、ユーザ側（ポリシーの仕様）に影響しない内容を > まず1.6.9としてリリースするわけにはいきませんか？ 1.6.8p1 以後、何も変更されていないので、 1.6.9 としてリリースする 内容がありません。 2.6.31 に対応したものを新しい tar ball にするくらいです。 From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Sat Aug 22 09:54:25 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sat, 22 Aug 2009 09:54:25 +0900 Subject: [Tomoyo-dev 1161] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908200301.n7K31W40021056@www262.sakura.ne.jp> References: <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> <200908200301.n7K31W40021056@www262.sakura.ne.jp> Message-ID: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> 　熊猫です。 　以下の指定ではどうでしょう？ グローバルモード設定= disabled learning permissive enforcing のいづれか 　0-MAC=disabled 　1-MAC=learning no_grant_log no_reject_log 　2-MAC=permissive no_grant_log 　3-MAC=enforcing no_grant_log カテゴリ別モード設定=disabled learning permissive enforcing default のいづれか 　4-MAC::file=permissive no_grant_log 　4-MAC::network=learning no_reject_log 項目別モード設定=disabled learning permissive enforcing default のいづれか 　4-MAC::file::execute=enforcing 　4-MAC::file::open=learning 　4-MAC::file::pivot_root=disabled 　3-MAC::network::tcp_bind=learning 　3-MAC::network::tcp_listen=learning 　3-MAC::network::tcp_connect=learning 　3-MAC::network::tcp_accept=learning no_grant_log 　3-MAC::network::udp_bind=enforcing no_grant_log no_reject_log 　3-MAC::network::udp_connect=enforcing no_grant_log no_reject_log 　3-MAC::network::raw_bind=learning no_grant_log 　3-MAC::network::raw_connect=learning no_grant_log 優先順位は （１）項目別モード設定が default の場合はカテゴリ別モード設定を使用 （２）カテゴリ別モード設定が default の場合はグローバルモード設定を使用 （３）グローバルモード設定が指定されていない場合には disabled とする この他に、今後 3-MAC::foo::bar が追加されたときに 3-MAC=enforcing という デフォルト指定により 3-MAC::foo::bar=enforcing として解釈されてしまわないように プロファイル番号単位の指定とは別に PROFILE_VERSION=20090903 のような指定が 必要になります。 グローバルモード設定が指定されていない場合、そのプロファイル番号は （ disabled が指定されたものとして扱うよりも） use_profile で指定できないもの として扱うべき？ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Mon Aug 24 17:30:15 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Mon, 24 Aug 2009 17:30:15 +0900 Subject: [Tomoyo-dev 1162] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> References: <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> <200908200301.n7K31W40021056@www262.sakura.ne.jp> <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> Message-ID: <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> 　熊猫です。 　以下のようにしてみました。（ revision 2946 ） グローバルモード設定= disabled learning permissive enforcing のいづれか （グローバルモード未指定時は disabled として扱う） 　0-MAC=disabled 　1-MAC=learning no_grant_log no_reject_log 　2-MAC=permissive no_grant_log 　3-MAC=enforcing no_grant_log カテゴリ別モード設定=disabled learning permissive enforcing のいづれか （カテゴリ別モード未指定時はグローバルモード設定を使用） 　4-MAC::file=permissive no_grant_log 　4-MAC::network=learning no_reject_log 項目別モード設定=disabled learning permissive enforcing のいづれか （項目別モード未指定時はカテゴリ別設定を使用） 　4-MAC::file::execute=enforcing 　4-MAC::file::open=learning 　4-MAC::file::pivot_root=disabled 　3-MAC::network::inet_tcp_bind=learning 　3-MAC::network::inet_tcp_listen=learning 　3-MAC::network::inet_tcp_connect=learning 　3-MAC::network::inet_tcp_accept=learning no_grant_log 　3-MAC::network::inet_udp_bind=enforcing no_grant_log no_reject_log 　3-MAC::network::inet_udp_connect=enforcing no_grant_log no_reject_log 　3-MAC::network::inet_raw_bind=learning no_grant_log 　3-MAC::network::inet_raw_connect=learning no_grant_log /proc/ccs/profile の読み出し時に、モード未指定の項目は表示されない。 カテゴリ別モード設定または項目別モード設定で default を指定すると （モード未指定状態になることにより）表示されなくなる。 From hiroshi.shinji ＠ gmail.com Wed Aug 26 14:15:54 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Wed, 26 Aug 2009 14:15:54 +0900 Subject: [Tomoyo-dev 1163] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> References: <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> <200908200301.n7K31W40021056@www262.sakura.ne.jp> <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> Message-ID: 宍道です。 > 以下のようにしてみました。（ revision 2946 ） 設定方法については良い感じだと思います。 ただ、revision 2951 を使って学習モードで動作させたんですが、 学習結果を保存し、再度リブートして立ち上げると、 学習したはずなのに、WARNINGが出てきます。 ..... WARNING: Access execute /sbin/init denied for WARNING: Access execute /bin/mount denied for /sbin/init WARNING: Access execute /bin/mount denied for /sbin/init WARNING: Access execute /bin/sh denied for /sbin/init WARNING: Access execute /bin/mount denied for /bin/sh WARNING: Access execute /bin/mkdir denied for /sbin/init WARNING: Access execute /bin/mount denied for /sbin/init WARNING: Access execute /bin/sh denied for /sbin/init WARNING: Access execute /bin/echo denied for /bin/sh WARNING: Access execute /sbin/mdev denied for /sbin/init WARNING: Access execute /bin/mount denied for /sbin/init WARNING: Access execute /bin/mount denied for /sbin/init WARNING: Access execute /bin/hostname denied for /sbin/init WARNING: Access execute /sbin/ifconfig denied for /sbin/init WARNING: Access execute /sbin/route denied for /sbin/init WARNING: Access execute /sbin/watchdog denied for /sbin/init WARNING: Access execute /etc/init.d/rcS denied for /sbin/init ...... ちなみに例として /sbin/init の学習した結果は以下の通りです。 このポリシーで何度起動してもWARNINGが出てきます。 /sbin/init use_profile 1 allow_capability SYS_IOCTL allow_capability SYS_REBOOT allow_env HOME allow_env TERM allow_execute /bin/hostname if exec.realpath="/bin/busybox" exec.argv[0]="hostname" allow_execute /bin/mkdir if exec.realpath="/bin/busybox" exec.argv[0]="mkdir" allow_execute /bin/mount if exec.realpath="/bin/busybox" exec.argv[0]="mount" allow_execute /bin/sh if exec.realpath="/bin/busybox" exec.argv[0]="sh" allow_execute /bin/touch if exec.realpath="/bin/busybox" exec.argv[0]="touch" allow_execute /etc/init.d/rcS if exec.realpath="/etc/init.d/rcS" exec.argv[0]="rcS" allow_execute /sbin/getty if exec.realpath="/bin/busybox" exec.argv[0]="getty" allow_execute /sbin/ifconfig if exec.realpath="/bin/busybox" exec.argv[0]="ifconfig" allow_execute /sbin/klogd if exec.realpath="/bin/busybox" exec.argv[0]="klogd" allow_execute /sbin/mdev if exec.realpath="/bin/busybox" exec.argv[0]="mdev" allow_execute /sbin/route if exec.realpath="/bin/busybox" exec.argv[0]="route" allow_execute /sbin/syslogd if exec.realpath="/bin/busybox" exec.argv[0]="syslogd" allow_execute /sbin/watchdog if exec.realpath="/bin/busybox" exec.argv[0]="watchdog" allow_ioctl /dev/console 0x402C7413 allow_ioctl /dev/console 0x5600 allow_ioctl /dev/console 0x802C7414 allow_ioctl /dev/null 0x402C7413 allow_ioctl /dev/null 0x802C7414 allow_ioctl /dev/ttyS0 0x402C7413 allow_ioctl /dev/ttyS0 0x802C7414 allow_ioctl /etc/inittab 0x402C7413 allow_read /etc/TZ allow_read /etc/inittab allow_read/write /dev/null allow_read/write /dev/ttyS0 学習は出来てるようなんですが、判定がうまくいっていないようです… よろしくお願いします。 2009/08/24 17:30 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > 以下のようにしてみました。（ revision 2946 ） > > グローバルモード設定= disabled learning permissive enforcing のいづれか > （グローバルモード未指定時は disabled として扱う） > > 0-MAC=disabled > 1-MAC=learning no_grant_log no_reject_log > 2-MAC=permissive no_grant_log > 3-MAC=enforcing no_grant_log > > カテゴリ別モード設定=disabled learning permissive enforcing のいづれか > （カテゴリ別モード未指定時はグローバルモード設定を使用） > > 4-MAC::file=permissive no_grant_log > 4-MAC::network=learning no_reject_log > > 項目別モード設定=disabled learning permissive enforcing のいづれか > （項目別モード未指定時はカテゴリ別設定を使用） > > 4-MAC::file::execute=enforcing > 4-MAC::file::open=learning > 4-MAC::file::pivot_root=disabled > 　3-MAC::network::inet_tcp_bind=learning > 3-MAC::network::inet_tcp_listen=learning > 3-MAC::network::inet_tcp_connect=learning > 3-MAC::network::inet_tcp_accept=learning no_grant_log > 3-MAC::network::inet_udp_bind=enforcing no_grant_log no_reject_log > 3-MAC::network::inet_udp_connect=enforcing no_grant_log no_reject_log > 3-MAC::network::inet_raw_bind=learning no_grant_log > 3-MAC::network::inet_raw_connect=learning no_grant_log > > /proc/ccs/profile の読み出し時に、モード未指定の項目は表示されない。 > カテゴリ別モード設定または項目別モード設定で default を指定すると > （モード未指定状態になることにより）表示されなくなる。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Wed Aug 26 18:45:33 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Wed, 26 Aug 2009 18:45:33 +0900 Subject: [Tomoyo-dev 1164] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> <200908200301.n7K31W40021056@www262.sakura.ne.jp> <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> Message-ID: <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> 　熊猫です。 > ただ、revision 2951 を使って学習モードで動作させたんですが、 > 学習結果を保存し、再度リブートして立ち上げると、 > 学習したはずなのに、WARNINGが出てきます。 テストありがとうございました。 ccs_get_argv0() 内の } else if (c == '/') { arg_len = 0; によって argv[0] の最後の / 以降だけを if 節の exec.argv[0] として 追加してしまっていたためですね。 revision 2958 で（プロファイルの変更と一緒に）修正しました。 From hiroshi.shinji ＠ gmail.com Wed Aug 26 22:04:26 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Wed, 26 Aug 2009 22:04:26 +0900 Subject: [Tomoyo-dev 1165] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> References: <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> <200908200301.n7K31W40021056@www262.sakura.ne.jp> <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> Message-ID: 宍道です。 > revision 2958 で（プロファイルの変更と一緒に）修正しました。 ありがとうございます。 後で確認します。 ところで、プロファイルがまた変更されているのを sourceforge 上で init_policy.c を見て確認しました。 この中で、各モードでそれぞれ PREFERENCE::enforcing PREFERENCE::learning PREFERENCE::permissive が設定されているのは何を意味しているでしょう？ 2009/08/26 18:45 に さんは書きました: > 　熊猫です。 > >> ただ、revision 2951 を使って学習モードで動作させたんですが、 >> 学習結果を保存し、再度リブートして立ち上げると、 >> 学習したはずなのに、WARNINGが出てきます。 > > テストありがとうございました。 > > ccs_get_argv0() 内の > > } else if (c == '/') { > arg_len = 0; > > によって argv[0] の最後の / 以降だけを if 節の exec.argv[0] として > 追加してしまっていたためですね。 > revision 2958 で（プロファイルの変更と一緒に）修正しました。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Wed Aug 26 22:42:35 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Wed, 26 Aug 2009 22:42:35 +0900 Subject: [Tomoyo-dev 1166] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> Message-ID: <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> 　熊猫です。 ＃ tomoyo-users-en 89 を見て、 tomoyo-dev 1164 の続きを書くのを忘れてた。（笑） Hiroshi Shinji さんは書きました： > ところで、プロファイルがまた変更されているのを > sourceforge 上で init_policy.c を見て確認しました。 > この中で、各モードでそれぞれ > PREFERENCE::enforcing > PREFERENCE::learning > PREFERENCE::permissive > が設定されているのは何を意味しているでしょう？ アクセス制御以外の項目も見直しを行った結果です。 プロファイルは 番号-COMMENT=このプロファイルについてのコメント 番号-PREFERENCE::audit={ アクセスログに関する設定 } 番号-PREFERENCE::enforcing={ 強制モードに関する設定 } 番号-PREFERENCE::learning={ 学習モードに関する設定 } 番号-PREFERENCE::permissive={ 確認モードに関する設定 } 番号-CONFIG={ 制御モードおよびアクセスログの指定 } という（デフォルトで）６行で表現できる形になりました。 CONFIG はアクセス制御の指定、 PREFERENCE はアクセス制御以外の指定です。 「制御モードおよびアクセスログの指定」の中は mode= disabled または learning または permissive または enforcing grant_log= yes または no reject_log= yes または no です。 設定例を示します。 # cat /proc/ccs/profile 0-COMMENT=-----Disabled Mode----- 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 0-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } 0-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } 0-PREFERENCE::permissive={ verbose=yes } 0-PREFERENCE::enforcing={ verbose=yes penalty=0 } 1-COMMENT=-----Learning Mode----- 1-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 1-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } 1-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } 1-PREFERENCE::permissive={ verbose=yes } 1-PREFERENCE::enforcing={ verbose=yes penalty=0 } 2-COMMENT=-----Permissive Mode----- 2-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 2-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } 2-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } 2-PREFERENCE::permissive={ verbose=yes } 2-PREFERENCE::enforcing={ verbose=yes penalty=0 } 3-COMMENT=-----Enforcing Mode----- 3-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 3-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } 3-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } 3-PREFERENCE::permissive={ verbose=yes } 3-PREFERENCE::enforcing={ verbose=yes penalty=0 } MAX_GRANT_LOG および MAX_REJECT_LOG は「アクセスログに関する設定」の中の max_grant_log= 1024 （または 0 以上の任意の整数） max_reject_log= 1024 （または 0 以上の任意の整数） に置き換えられました。 MAX_ACCEPT_ENTRY および AUTOLEARN_EXEC_REALPATH および AUTOLEARN_EXEC_ARGV0 は 「学習モードに関する設定」の中の max_entry= 1024 （または 0 以上の任意の整数） exec.realpath= yes または no exec.argv0= yes または no に置き換えられました。 SLEEP_PERIOD は「強制モードに関する設定」の中の penalty= 0 （または任意の自然数） に置き換えられました。 PRINT_VIOLATION は「学習モードに関する設定」「確認モードに関する設定」 「強制モードに関する設定」の中の verbose= yes または no に置き換えられました。（プロファイル単位で verbose かどうかではなく、 プロファイル／モード単位で verbose かどうか指定できるようにしました。） なお、 番号-CONFIG={ 制御モードおよびアクセスログの指定 } については 番号-CONFIG::file={ ファイルアクセスに関する制御モードおよびアクセスログの指定 } や 番号-CONFIG::file::execute={ プログラム実行に関する制御モードおよびアクセスログの指定 } のような形でグローバル設定をオーバーライドできます。 （オーバーライドした場合、その分行数が増えます。） From hiroshi.shinji ＠ gmail.com Wed Aug 26 23:30:28 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Wed, 26 Aug 2009 23:30:28 +0900 Subject: [Tomoyo-dev 1167] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> References: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> Message-ID: 宍道です。 > 設定例を示します。 > > # cat /proc/ccs/profile > 0-COMMENT=-----Disabled Mode----- > 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 0-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 0-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 0-PREFERENCE::permissive={ verbose=yes } > 0-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 1-COMMENT=-----Learning Mode----- > 1-CONFIG={ mode=disabled grant_log=yes reject_log=yes } "mode=learning"　ですよね？（コピペで修正し損ね？ 以下も） > 1-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 1-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 1-PREFERENCE::permissive={ verbose=yes } > 1-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 2-COMMENT=-----Permissive Mode----- > 2-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 2-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 2-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 2-PREFERENCE::permissive={ verbose=yes } > 2-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 3-COMMENT=-----Enforcing Mode----- > 3-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 3-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 3-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 3-PREFERENCE::permissive={ verbose=yes } > 3-PREFERENCE::enforcing={ verbose=yes penalty=0 } この中で例えばプロファイル番号１の Learning Mode で、 permissiveやenforcingの設定をしているのはなぜでしょう？ それとPREFERENCEの記述が、上記の例ではすべて同じなんですが、 その場合、どっかにまとめて書けないでしょうかねぇ。 例えば、先頭に X-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } X-PREFERENCE::permissive={ verbose=yes } X-PREFERENCE::enforcing={ verbose=yes penalty=0 } として、これを基本設定にするとか。 2009/08/26 22:42 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > ＃ tomoyo-users-en 89 を見て、 tomoyo-dev 1164 の続きを書くのを忘れてた。（笑） > > Hiroshi Shinji さんは書きました： >> ところで、プロファイルがまた変更されているのを >> sourceforge 上で init_policy.c を見て確認しました。 >> この中で、各モードでそれぞれ >> PREFERENCE::enforcing >> PREFERENCE::learning >> PREFERENCE::permissive >> が設定されているのは何を意味しているでしょう？ > > アクセス制御以外の項目も見直しを行った結果です。 > プロファイルは > > 番号-COMMENT=このプロファイルについてのコメント > 番号-PREFERENCE::audit={ アクセスログに関する設定 } > 番号-PREFERENCE::enforcing={ 強制モードに関する設定 } > 番号-PREFERENCE::learning={ 学習モードに関する設定 } > 番号-PREFERENCE::permissive={ 確認モードに関する設定 } > 番号-CONFIG={ 制御モードおよびアクセスログの指定 } > > という（デフォルトで）６行で表現できる形になりました。 > CONFIG はアクセス制御の指定、 PREFERENCE はアクセス制御以外の指定です。 > > 「制御モードおよびアクセスログの指定」の中は > > mode= disabled または learning または permissive または enforcing > grant_log= yes または no > reject_log= yes または no > > です。 > > 設定例を示します。 > > # cat /proc/ccs/profile > 0-COMMENT=-----Disabled Mode----- > 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 0-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 0-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 0-PREFERENCE::permissive={ verbose=yes } > 0-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 1-COMMENT=-----Learning Mode----- > 1-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 1-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 1-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 1-PREFERENCE::permissive={ verbose=yes } > 1-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 2-COMMENT=-----Permissive Mode----- > 2-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 2-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 2-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 2-PREFERENCE::permissive={ verbose=yes } > 2-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 3-COMMENT=-----Enforcing Mode----- > 3-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 3-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 3-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 3-PREFERENCE::permissive={ verbose=yes } > 3-PREFERENCE::enforcing={ verbose=yes penalty=0 } > > > MAX_GRANT_LOG および MAX_REJECT_LOG は「アクセスログに関する設定」の中の > > max_grant_log= 1024 （または 0 以上の任意の整数） > max_reject_log= 1024 （または 0 以上の任意の整数） > > に置き換えられました。 > > MAX_ACCEPT_ENTRY および AUTOLEARN_EXEC_REALPATH および AUTOLEARN_EXEC_ARGV0 は > 「学習モードに関する設定」の中の > > max_entry= 1024 （または 0 以上の任意の整数） > exec.realpath= yes または no > exec.argv0= yes または no > > に置き換えられました。 > > SLEEP_PERIOD は「強制モードに関する設定」の中の > > penalty= 0 （または任意の自然数） > > に置き換えられました。 > > PRINT_VIOLATION は「学習モードに関する設定」「確認モードに関する設定」 > 「強制モードに関する設定」の中の > > verbose= yes または no > > に置き換えられました。（プロファイル単位で verbose かどうかではなく、 > プロファイル／モード単位で verbose かどうか指定できるようにしました。） > > なお、 > > 番号-CONFIG={ 制御モードおよびアクセスログの指定 } > > については > > 番号-CONFIG::file={ ファイルアクセスに関する制御モードおよびアクセスログの指定 } > > や > > 番号-CONFIG::file::execute={ プログラム実行に関する制御モードおよびアクセスログの指定 } > > のような形でグローバル設定をオーバーライドできます。 > （オーバーライドした場合、その分行数が増えます。） > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From hiroshi.shinji ＠ gmail.com Wed Aug 26 23:41:45 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Wed, 26 Aug 2009 23:41:45 +0900 Subject: [Tomoyo-dev 1168] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908180829.n7I8TmgB079119@www262.sakura.ne.jp> <200908192106.BAJ81207.PUtZtNESGWPNPFP@I-love.SAKURA.ne.jp> <200908200301.n7K31W40021056@www262.sakura.ne.jp> <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> Message-ID: 宍道です。 >> revision 2958 で（プロファイルの変更と一緒に）修正しました。 > > ありがとうございます。 > 後で確認します。 CONFIG_CCSECURITY_AUDIT を 「N」にした場合、 policy_io.c で、CONFIG_CCSECURITY_MAX_GRANT_LOG と CONFIG_CCSECURITY_MAX_REJECT_LOG が無いと言ってエラーが出ます。 ... CC security/ccsecurity/policy_io.o security/ccsecurity/policy_io.c: In function 'ccs_find_or_assign_new_profile': security/ccsecurity/policy_io.c:247: error: 'CONFIG_CCSECURITY_MAX_GRANT_LOG' undeclared (first use in this function) security/ccsecurity/policy_io.c:247: error: (Each undeclared identifier is reported only once security/ccsecurity/policy_io.c:247: error: for each function it appears in.) security/ccsecurity/policy_io.c:248: error: 'CONFIG_CCSECURITY_MAX_REJECT_LOG' undeclared (first use in this function) .... CONFIG_CCSECURITY_AUDIT を「Y」にして MAX_GRANT_LOG と MAX_REJECT_LOG を 0 にすれば通りますが。 2009/08/26 22:04 に Hiroshi Shinji さんは書きました: > 宍道です。 > >> revision 2958 で（プロファイルの変更と一緒に）修正しました。 > > ありがとうございます。 > 後で確認します。 > > ところで、プロファイルがまた変更されているのを > sourceforge 上で init_policy.c を見て確認しました。 > この中で、各モードでそれぞれ > PREFERENCE::enforcing > PREFERENCE::learning > PREFERENCE::permissive > が設定されているのは何を意味しているでしょう？ > > > > 2009/08/26 18:45 に さんは書きました: >> 熊猫です。 >> >>> ただ、revision 2951 を使って学習モードで動作させたんですが、 >>> 学習結果を保存し、再度リブートして立ち上げると、 >>> 学習したはずなのに、WARNINGが出てきます。 >> >> テストありがとうございました。 >> >> ccs_get_argv0() 内の >> >> } else if (c == '/') { >> arg_len = 0; >> >> によって argv[0] の最後の / 以降だけを if 節の exec.argv[0] として >> 追加してしまっていたためですね。 >> revision 2958 で（プロファイルの変更と一緒に）修正しました。 >> >> _______________________________________________ >> tomoyo-dev mailing list >> tomoyo-dev ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev >> > > > > -- > 宍道 洋 > hiroshi.shinji ＠ gmail.com > http://d.hatena.ne.jp/hshinji/ > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 27 09:43:30 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 27 Aug 2009 09:43:30 +0900 Subject: [Tomoyo-dev 1169] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> Message-ID: <200908270043.n7R0hUxO013764@www262.sakura.ne.jp> 　熊猫です。 > "mode=learning"　ですよね？（コピペで修正し損ね？ 以下も） はい。 /etc/ccs/profile.conf の更新し忘れです。（＾＾； # cat /proc/ccs/profile 0-COMMENT=-----Disabled Mode----- 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 0-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } 0-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } 0-PREFERENCE::permissive={ verbose=yes } 0-PREFERENCE::enforcing={ verbose=yes penalty=0 } 1-COMMENT=-----Learning Mode----- 1-CONFIG={ mode=learning grant_log=yes reject_log=yes } 1-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } 1-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } 1-PREFERENCE::permissive={ verbose=yes } 1-PREFERENCE::enforcing={ verbose=yes penalty=0 } 2-COMMENT=-----Permissive Mode----- 2-CONFIG={ mode=permissive grant_log=yes reject_log=yes } 2-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } 2-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } 2-PREFERENCE::permissive={ verbose=yes } 2-PREFERENCE::enforcing={ verbose=yes penalty=0 } 3-COMMENT=-----Enforcing Mode----- 3-CONFIG={ mode=enforcing grant_log=yes reject_log=yes } 3-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } 3-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } 3-PREFERENCE::permissive={ verbose=yes } 3-PREFERENCE::enforcing={ verbose=yes penalty=0 } > この中で例えばプロファイル番号１の Learning Mode で、 > permissiveやenforcingの設定をしているのはなぜでしょう？ プロファイル番号１で mode=learning ではない CONFIG が作成されないとは限らない （例えば 1-CONFIG::network={ mode=permissive grant_log=yes reject_log=yes } という項目が追加される可能性がある）からです。 PREFERENCE はモードを指定するための項目ではなく、モードに関するパラメータを 指定するための項目なので、そのモードが使われていなくても存在します。 > それとPREFERENCEの記述が、上記の例ではすべて同じなんですが、 デフォルト設定値のままだから同じなだけです。 > その場合、どっかにまとめて書けないでしょうかねぇ。 > 例えば、先頭に > X-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes > exec.argv0=yes } > X-PREFERENCE::permissive={ verbose=yes } > X-PREFERENCE::enforcing={ verbose=yes penalty=0 } > として、これを基本設定にするとか。 ccs-editpolicy のプロファイル編集画面では「番号-項目=値」という書式で 扱っているのですが、とうとう「項目=値」という書式で扱う必要が出てしまった ようですね。まぁ、プロファイルのバージョン指定も必要になったことですし、 変更することになるのでしょう。 > CONFIG_CCSECURITY_AUDIT を 「N」にした場合、 > policy_io.c で、CONFIG_CCSECURITY_MAX_GRANT_LOG と > CONFIG_CCSECURITY_MAX_REJECT_LOG が無いと言ってエラーが出ます。 こちらは revision 2959 で修正しました。 From hiroshi.shinji ＠ gmail.com Thu Aug 27 10:56:43 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Thu, 27 Aug 2009 10:56:43 +0900 Subject: [Tomoyo-dev 1170] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908270043.n7R0hUxO013764@www262.sakura.ne.jp> References: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> <200908270043.n7R0hUxO013764@www262.sakura.ne.jp> Message-ID: 宍道です。 プロファイルに関する回答と、コンパイルエラーの修正、ありがとうございます。 そのほかで、動作させて気になったところが一つあります。 まず、keep_domain で、コンソールログイン時には、ドメイン遷移しないように指定します。 keep_domain /sbin/init /sbin/getty /bin/login /bin/sh そしてこのドメインのみ disabled にして、他のドメインを全て learning にして学習すると、 なぜか、上記のドメインでは disabled なのに「環境変数だけ」学習されてしまいます。 以下 ccs-editpolicy の画面から。 /sbin/init /sbin/getty /bin/login /bin/sh 0: allow_env HOME 1: allow_env LOGNAME 2: allow_env PATH 3: allow_env SHELL 4: allow_env TERM 5: allow_env USER よろしくお願いします。 2009/08/27 9:43 に さんは書きました: > 　熊猫です。 > >> "mode=learning"　ですよね？（コピペで修正し損ね？ 以下も） > はい。 /etc/ccs/profile.conf の更新し忘れです。（＾＾； > > # cat /proc/ccs/profile > 0-COMMENT=-----Disabled Mode----- > 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 0-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 0-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 0-PREFERENCE::permissive={ verbose=yes } > 0-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 1-COMMENT=-----Learning Mode----- > 1-CONFIG={ mode=learning grant_log=yes reject_log=yes } > 1-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 1-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 1-PREFERENCE::permissive={ verbose=yes } > 1-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 2-COMMENT=-----Permissive Mode----- > 2-CONFIG={ mode=permissive grant_log=yes reject_log=yes } > 2-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 2-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 2-PREFERENCE::permissive={ verbose=yes } > 2-PREFERENCE::enforcing={ verbose=yes penalty=0 } > 3-COMMENT=-----Enforcing Mode----- > 3-CONFIG={ mode=enforcing grant_log=yes reject_log=yes } > 3-PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > 3-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes } > 3-PREFERENCE::permissive={ verbose=yes } > 3-PREFERENCE::enforcing={ verbose=yes penalty=0 } > >> この中で例えばプロファイル番号１の Learning Mode で、 >> permissiveやenforcingの設定をしているのはなぜでしょう？ > プロファイル番号１で mode=learning ではない CONFIG が作成されないとは限らない > （例えば 1-CONFIG::network={ mode=permissive grant_log=yes reject_log=yes } > という項目が追加される可能性がある）からです。 > PREFERENCE はモードを指定するための項目ではなく、モードに関するパラメータを > 指定するための項目なので、そのモードが使われていなくても存在します。 > >> それとPREFERENCEの記述が、上記の例ではすべて同じなんですが、 > デフォルト設定値のままだから同じなだけです。 > >> その場合、どっかにまとめて書けないでしょうかねぇ。 >> 例えば、先頭に >> X-PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes >> exec.argv0=yes } >> X-PREFERENCE::permissive={ verbose=yes } >> X-PREFERENCE::enforcing={ verbose=yes penalty=0 } >> として、これを基本設定にするとか。 > ccs-editpolicy のプロファイル編集画面では「番号-項目=値」という書式で > 扱っているのですが、とうとう「項目=値」という書式で扱う必要が出てしまった > ようですね。まぁ、プロファイルのバージョン指定も必要になったことですし、 > 変更することになるのでしょう。 > > >> CONFIG_CCSECURITY_AUDIT を 「N」にした場合、 >> policy_io.c で、CONFIG_CCSECURITY_MAX_GRANT_LOG と >> CONFIG_CCSECURITY_MAX_REJECT_LOG が無いと言ってエラーが出ます。 > こちらは revision 2959 で修正しました。 > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ i-love.sakura.ne.jp Thu Aug 27 11:31:53 2009 From: from-tomoyo-dev ＠ i-love.sakura.ne.jp (from-tomoyo-dev ＠ i-love.sakura.ne.jp) Date: Thu, 27 Aug 2009 11:31:53 +0900 Subject: [Tomoyo-dev 1171] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> <200908270043.n7R0hUxO013764@www262.sakura.ne.jp> Message-ID: <200908270231.n7R2VrEY038691@www262.sakura.ne.jp> 　熊猫です。 > なぜか、上記のドメインでは disabled なのに「環境変数だけ」学習されてしまいます。 ありがとうございます。 r.profile に遷移前のドメインのプロファイル番号が入っていたためです。 遷移先ドメイン（ r.domain に入っている）でのプロファイル番号を使って モードを取得する必要がありますね。 Index: domain.c =================================================================== --- domain.c (revision 2959) +++ domain.c (working copy) @@ -1267,7 +1267,7 @@ ok: if (retval < 0) goto out; - ee->r.mode = ccs_get_mode(ee->r.profile, CCS_MAC_ENVIRON); + ee->r.mode = ccs_get_mode(ee->r.domain->profile, CCS_MAC_ENVIRON); retval = ccs_environ(ee); if (retval < 0) goto out; From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu Aug 27 17:52:35 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 27 Aug 2009 17:52:35 +0900 Subject: [Tomoyo-dev 1172] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> Message-ID: <200908270852.n7R8qZnY025697@www262.sakura.ne.jp> 　熊猫です。 Hiroshi Shinji wrote: > それとPREFERENCEの記述が、上記の例ではすべて同じなんですが、 > その場合、どっかにまとめて書けないでしょうかねぇ。 revision 2962 でそのようになりました。 # cat /proc/ccs/profile PROFILE_VERSION=20090827 PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes symlink.target=yes } PREFERENCE::permissive={ verbose=yes } PREFERENCE::enforcing={ verbose=yes penalty=0 } 0-COMMENT=-----Disabled Mode----- 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 1-COMMENT=-----Learning Mode----- 1-CONFIG={ mode=learning grant_log=yes reject_log=yes } 2-COMMENT=-----Permissive Mode----- 2-CONFIG={ mode=permissive grant_log=yes reject_log=yes } 3-COMMENT=-----Enforcing Mode----- 3-CONFIG={ mode=enforcing grant_log=yes reject_log=yes } From hiroshi.shinji ＠ gmail.com Thu Aug 27 20:36:06 2009 From: hiroshi.shinji ＠ gmail.com (Hiroshi Shinji) Date: Thu, 27 Aug 2009 20:36:06 +0900 Subject: [Tomoyo-dev 1173] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908270852.n7R8qZnY025697@www262.sakura.ne.jp> References: <200908220954.BJE81753.NSPtWPPFNEPUtZG@I-love.SAKURA.ne.jp> <200908240830.n7O8UFTV079789@www262.sakura.ne.jp> <200908260945.n7Q9jXbM007680@www262.sakura.ne.jp> <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> <200908270852.n7R8qZnY025697@www262.sakura.ne.jp> Message-ID: 宍道です。 > revision 2962 でそのようになりました。 > > # cat /proc/ccs/profile > PROFILE_VERSION=20090827 > PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes symlink.target=yes } > PREFERENCE::permissive={ verbose=yes } > PREFERENCE::enforcing={ verbose=yes penalty=0 } > 0-COMMENT=-----Disabled Mode----- > 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 1-COMMENT=-----Learning Mode----- > 1-CONFIG={ mode=learning grant_log=yes reject_log=yes } > 2-COMMENT=-----Permissive Mode----- > 2-CONFIG={ mode=permissive grant_log=yes reject_log=yes } > 3-COMMENT=-----Enforcing Mode----- > 3-CONFIG={ mode=enforcing grant_log=yes reject_log=yes } おぉ、すばらしい！ すっきりしましたねぇ。 2009/08/27 17:52 に Tetsuo Handa さんは書きました: > 　熊猫です。 > > Hiroshi Shinji wrote: >> それとPREFERENCEの記述が、上記の例ではすべて同じなんですが、 >> その場合、どっかにまとめて書けないでしょうかねぇ。 > revision 2962 でそのようになりました。 > > # cat /proc/ccs/profile > PROFILE_VERSION=20090827 > PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes symlink.target=yes } > PREFERENCE::permissive={ verbose=yes } > PREFERENCE::enforcing={ verbose=yes penalty=0 } > 0-COMMENT=-----Disabled Mode----- > 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > 1-COMMENT=-----Learning Mode----- > 1-CONFIG={ mode=learning grant_log=yes reject_log=yes } > 2-COMMENT=-----Permissive Mode----- > 2-CONFIG={ mode=permissive grant_log=yes reject_log=yes } > 3-COMMENT=-----Enforcing Mode----- > 3-CONFIG={ mode=enforcing grant_log=yes reject_log=yes } > > _______________________________________________ > tomoyo-dev mailing list > tomoyo-dev ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev > -- 宍道 洋 hiroshi.shinji ＠ gmail.com http://d.hatena.ne.jp/hshinji/ From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Thu Aug 27 20:50:48 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Thu, 27 Aug 2009 20:50:48 +0900 Subject: [Tomoyo-dev 1174] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: References: <200908262242.DDG65162.WtPPtFZPPNENSGU@I-love.SAKURA.ne.jp> <200908270852.n7R8qZnY025697@www262.sakura.ne.jp> Message-ID: <200908272050.ADH69721.FtPEPUGPWtNPNSZ@I-love.SAKURA.ne.jp> 　熊猫です。 Hiroshi Shinji さんは書きました： > > # cat /proc/ccs/profile > > PROFILE_VERSION=20090827 > > PREFERENCE::audit={ max_grant_log=1024 max_reject_log=1024 } > > PREFERENCE::learning={ verbose=no max_entry=2048 exec.realpath=yes exec.argv0=yes symlink.target=yes } > > PREFERENCE::permissive={ verbose=yes } > > PREFERENCE::enforcing={ verbose=yes penalty=0 } > > 0-COMMENT=-----Disabled Mode----- > > 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } > > 1-COMMENT=-----Learning Mode----- > > 1-CONFIG={ mode=learning grant_log=yes reject_log=yes } > > 2-COMMENT=-----Permissive Mode----- > > 2-CONFIG={ mode=permissive grant_log=yes reject_log=yes } > > 3-COMMENT=-----Enforcing Mode----- > > 3-CONFIG={ mode=enforcing grant_log=yes reject_log=yes } > > おぉ、すばらしい！ > > すっきりしましたねぇ。 では、 TOMOYO 1.7 および TOMOYO 2.3 は上記のような指定方法で行きたいと思います。 （コンパイルエラーを修正して 2963 になりました。） 「番号-PREFERENCE::項目=値」という設定を行うと、その項目に関しては 「PREFERENCE::項目=値」という設定を使わなくなります。 「番号-PREFERENCE::項目=use_default」という設定を行うと、その項目に関して 「PREFERENCE::項目=値」という設定を使うようになります。 「番号-CONFIG::カテゴリ=値」という設定を行うと、そのカテゴリに関しては 「番号-CONFIG=値」という設定を使わなくなります。 「番号-CONFIG::カテゴリ=use_default」という設定を行うと、そのカテゴリに関して 「番号-CONFIG=値」という設定を使うようになります。 「番号-CONFIG::カテゴリ::項目=値」という設定を行うと、その項目に関しては 「番号-CONFIG::カテゴリ=値」という設定を使わなくなります。 「番号-CONFIG::カテゴリ::項目=use_default」という設定を行うと、その項目に関して 「番号-CONFIG::カテゴリ=値」という設定を使うようになります。 From henrich ＠ debian.or.jp Fri Aug 28 04:57:36 2009 From: henrich ＠ debian.or.jp (Hideki Yamane) Date: Fri, 28 Aug 2009 04:57:36 +0900 Subject: [Tomoyo-dev 1175] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> Message-ID: <20090828045736.0006bb4f.henrich@debian.or.jp> 　やまねです。 　パッケージのメンテナンスの点から確認です。 On Tue, 18 Aug 2009 14:26:37 +0900 Tetsuo Handa wrote: > 　TOMOYO 1.7 へ向けてそろそろ仕様を確定させようと思います。 　* 1.7 は 1.6.8 利用時からの migration が存在していないので、 　　profile をすべて破棄して作り直しになる？ (Y/n) 　　-> system_policy.conf が存在しているのならば /etc/ccs 内 　　　の .conf ファイルはすべて破棄する、でOK? 　* 1.6 系はメンテナンスモードになり、これからの利用としては 　　1.7 の方が推奨になる？ (Y/n) 　　-> 2.2 系を別に用意するのならば 1.6.8 系は 1.7 にして 　　　おかないと3つもパッケージが存在して色々コストが嵩むので -- Regards, Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp http://wiki.debian.org/HidekiYamane From from-tomoyo-dev ＠ I-love.SAKURA.ne.jp Fri Aug 28 10:45:56 2009 From: from-tomoyo-dev ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Fri, 28 Aug 2009 10:45:56 +0900 Subject: [Tomoyo-dev 1176] Re: =?iso-2022-jp?b?GyRCJVclbSVVJSElJCVrJE47WERqSn1LISROSlEbKEI=?= =?iso-2022-jp?b?GyRCOTkkSyREJCQkRhsoQg==?= In-Reply-To: <20090828045736.0006bb4f.henrich@debian.or.jp> References: <200908180526.n7I5QbTB041731@www262.sakura.ne.jp> <20090828045736.0006bb4f.henrich@debian.or.jp> Message-ID: <200908280145.n7S1juIm074916@www262.sakura.ne.jp> 　熊猫です。 Hideki Yamane さんは書きました： > 　* 1.7 は 1.6.8 利用時からの migration が存在していないので、 > 　　profile をすべて破棄して作り直しになる？ (Y/n) Yes. > 　　-> system_policy.conf が存在しているのならば /etc/ccs 内 > 　　　の .conf ファイルはすべて破棄する、でOK? 1.7 では /usr/lib/ccs/init_policy の処理時間が数分から数秒に短縮されたので、 post-install 処理で /usr/lib/ccs/init_policy を自動的に実行しても良いかと 思います。 しかし、 1.6 用のプロファイルが存在する場合に（ユーザの確認を経ずに） 自動的に破棄してしまうのはまずいと思います。ですから、 pre-install 処理で 1.6 用のプロファイルが存在していた場合には 1.7 用のツールをインストール させないようにするというのもありかと思います。 > 　* 1.6 系はメンテナンスモードになり、これからの利用としては > 　　1.7 の方が推奨になる？ (Y/n) Yes. ただし、 1.6 用ツールパッケージを 1.7 用で置き換えるのは待ってください。 1.6.8 -> 1.7.0 は修正量が多い（ revision 2965 時点で追加 9714 行、 削除 11276 行、全体で 16990 行）ですし、ドキュメントやツールの修正も 必要ですので、実際に導入してみて不具合が無いかどうかを確認するための テスト期間を設けようと思います。テスト期間中は 1.6 ／ 1.7 ／ 2.2 という ３つのバージョンを http://tomoyo.sourceforge.jp/ に表示します。 熊猫もテスト期間中は 1.7 用の yum レポジトリを作成しないつもりです。 > 　　-> 2.2 系を別に用意するのならば 1.6.8 系は 1.7 にして > 　　　おかないと3つもパッケージが存在して色々コストが嵩むので 2.3 は 1.7 の仕様の内、ＬＳＭで実現できる範囲で、なおかつメインラインからの 了承が得られた機能が反映される予定です。（ 1.6 -> 1.7 と同様に構文の見直しが 発生するので） 2.3 でも 2.2 からの migration は不可能になります。ですから、 2.x 用のツールパッケージに関しても 1.x 用のツールパッケージと同じことを 考えておく必要がありますね。