Tetsuo Handa
from-****@I-lov*****
2009年 9月 3日 (木) 22:13:01 JST
熊猫です。 TOMOYO 1.7.0 では TOMOYO 2.2.0 から得られたフィードバックを元に仕様の見直しと 機能強化を行いました。構文の変化を伴うため TOMOYO 1.6.x との互換性はありません。 TOMOYO 1.6.x については、これ以降の機能追加は行いませんが、サポートは継続 されますので、 TOMOYO 1.6.x を利用中の方はバージョンアップする必要はありません。 変更点 (1)不要になったメモリを解放する仕組みの導入 従来はポリシーを記憶するために一度割り当てられたメモリは、ポリシーの削除後も 解放されませんでした。 TOMOYO 1.7.0 ではガベージコレクタ機能を搭載したことにより、ポリシーを削除 すると自動的にメモリが解放されるようになりました。 (2)長いパス名のサポート 従来は文字列の最大長が4000バイト、1行の最大長が8192バイトという 制約がありました。そのため、4000バイトを超えるような長いパス名が要求された 場合、アクセスが拒否されるケースがありました。 TOMOYO 1.7.0 では、ドメイン名と argv[] と envp[] 以外は( kmalloc() で 割り当て可能な上限である)128キロバイトまでの文字列を扱えるようになりました。 (3)より詳細なプロファイル設定のサポート 従来はアクセス制御モードの指定は、カテゴリ(ファイル/ネットワークなど)単位 でしか行えませんでした。 TOMOYO 1.7.0 では、プロファイルの指定を細分化し、アクセス制御モード/アクセス ログの要・不要/ポリシー違反時にエラーメッセージを表示するかどうか/学習モードで if 節の学習をするかどうかの指定を項目単位で行えるようになりました。このメールの 末尾にプロファイルの設定例を示します。 (4)ファイルの属性値のチェックを強化 ファイルやディレクトリなどを作成する際に、指定可能なモードを制限できるように なりました。デバイスファイルを作成する際には、メジャー番号/マイナー番号も制限 できるようになりました。 allow_create file_to_be_created create_mode allow_mkdir directory_to_be_created create_mode allow_mkfifo fifo_to_be_created create_mode allow_mksock unix_domain_socket_to_be_created create_mode allow_mkblock block_device_to_be_created create_mode major_number minor_number allow_mkchar block_device_to_be_created create_mode major_number minor_number ファイルやディレクトリなどのモードを変更したり、所有者やグループを変更したり する際に指定可能な値を制限できるようになりました。 allow_chmod path_to_be_mode_changed chmod_mode allow_chown path_to_be_owner_changed user_id allow_chgrp path_to_be_group_changed group_id これらの機能強化により、想定外の属性を持ったデバイスファイルの作成 (例: char-1-5 という属性を持った /dev/null というファイル)を禁止したり、 /bin/sh などのプログラムに setuid/setgid ビットを付与するのを禁止したり、 ユーザのホームディレクトリ内のファイルに execute ビットを付与するのを禁止したり することができるようになります。 名前空間の操作に関する制限はドメイン単位で行えるようになりました。 allow_mount path_to_device path_to_mountpoint filesystem_type flags allow_unmount path_to_unmount allow_chroot new_root_directory allow_pivot_root new_root old_root 以下に示すその他の構文は従来と同じです。 allow_symlink symlink_to_be_created allow_link old_path new_path allow_rename old_path new_path allow_ioctl path_to_be_io_controlled cmd_number allow_read/write path_to_be_opened_for_reading_and_writing allow_execute program_to_be_executed allow_read path_to_be_opened_for_reading allow_write path_to_be_opened_for_writing allow_unlink path_to_be_deleted allow_rmdir directory_to_be_deleted allow_truncate file_to_be_truncated allow_rewrite file_to_be_rewritten (5)数値をグループ化する number_group 構文を追加 パス名をグループ化する path_group 構文、IPアドレスをグループ化する address_group 構文に加えて、数値をグループ化する number_group 構文が追加 されました。DACのモードや所有者IDなども制限できるようになったわけですが、 単純な範囲指定だけでは記述しきれない場合があります。例えば 0640 0660 の両方を 指定したい場合、 allow_create /tmp/file 0640 allow_create /tmp/file 0660 のように繰り返しが必要になります。しかし、 number_group TMP_FILE_CREATE_MODES 0640 number_group TMP_FILE_CREATE_MODES 0660 のようにグループを定義してやることで、 allow_create /tmp/file @TMP_FILE_CREATE_MODES のように繰り返しを回避できます。 number_group 構文は、 TOMOYO を Android 上で動かす場合にも便利です。 ( http://sourceforge.jp/projects/tomoyo/docs/Part2_CELF_Android.pdf ) TOMOYO はUIDに基づくアクセス制限もサポートしているので、 allow_execute /bin/sh if task.uid!=0 のような制限が可能です。 Android ではアプリケーション毎に異なるUIDが 割り当てられますが、そのUIDはインストール時まで不明です。そのため、 アプリケーションとそのアプリケーション用のポリシーとを一緒に配布したくても、 allow_read /data/data/package1/\* if task.uid=????? のように、 ????? の部分を確定できません。しかし、 allow_read /data/data/package1/\* if task.uid=@PACKAGE1_DATA_READERS のようにUIDの部分を未定義のまま domain_policy.conf を作成し、 インストール時に判明したUIDを number_group PACKAGE1_DATA_READERS 10000 のように exception_policy.conf に追加することで対処できるようになるため、 アプリケーションとそのアプリケーション用のポリシーとを一緒に配布することが 容易になります。 (6) alias 構文および allow_argv0 構文を廃止 従来はシンボリックリンクの実行は alias 構文で明示されない限りシンボリック リンクを解決したパス名の実行許可をチェックしていました。 TOMOYO 1.7.0 では シンボリックリンクを解決する前のパス名の実行許可をチェックするようにし、 シンボリックリンクを解決した後のパス名は allow_execute 構文の if 節の exec.realpath 部分でチェックするようになりました。同様に、最初の引数( argv[0] )は allow_execute 構文の if 節の exec.argv[0] 部分でチェックするように なりました。 /sbin/pidof が /sbin/killall5 へのシンボリックリンクとして提供されている環境で /sbin/pidof を実行するためのアクセス許可は以下のようになります。 allow_execute /sbin/pidof if exec.realpath="/sbin/killall5" exec.argv[0]="/sbin/pidof" (7)インストール時間の短縮 従来は初期状態のポリシーを生成する際、 alias 構文を生成するためにディスク 全体からシンボリックリンクを検索する処理を行う必要があったので、完了まで数分を 要していました。 TOMOYO 1.7.0 ではその必要が無くなったため数秒で完了するようになりました。 (8) system_policy.conf を廃止 system_policy.conf で使われていた構文の内、特定のローカルポート番号が ポート番号に 0 を指定した bind() によって使われてしまうのを防ぐ deny_autobind 構文は exception_policy.conf へ移動、それ以外の構文は domain_policy.conf へ 移動しました。 (9) syaoran ファイルシステムを廃止 allow_mkblock および allow_mkchar でデバイス番号も制限できるようになり、 allow_chmod と allow_chown と allow_chgrp でモードや所有者ID・グループIDの 変更も制限できるようになったため、ファイルシステム自身で制限する必要性は 無くなりました。そのため、 syaoran ファイルシステムは廃止されました。 (10)排他制御の利用頻度を減らしたことによるボトルネックの解消 従来はメモリリークを検出するために TOMOYO 独自でメモリ使用量をカウントして いました。メモリリーク検出機能( CONFIG_DEBUG_KMEMLEAK )がカーネル 2.6.31 に マージされたことでもはや TOMOYO 独自でメモリリークを検出する必要性は無くなったと 判断し、メモリリークを検出するための排他制御が廃止されました。 (11)フックの修正 TOMOYO の機能を呼び出すためのフックである ccs-patch-2.\*.diff を LSM 風の フックとして書き直しました。幾つかのフックは LSM のフックのすぐ隣にあります。 kill tkill および tgkill に対してはフックが掛けられていましたが、 sigqueue および tgsigqueue に対するフックが抜けていたので追加されました。 open(pathname, O_RDONLY) はファイルを読み込みのためにオープン、 open(pathname, O_WRONLY) はファイルを書き込みのためにオープン、 open(pathname, O_RDWR) はファイルを読み書きのためにオープンする方法ですが、 その他に open(pathname, 3) という、 ioctl のためだけにオープンする方法が あることが判明しました。 TOMOYO ではファイルの open() 時にパーミッションをチェックしますが、 ファイルの read()/write() 時にはパーミッションをチェックしません。 従来は、 open(pathname, 3) が要求された場合に allow_read/write をチェックして いましたが、 read() や write() を行わないのに allow_read/write をチェックする のは構文の意図に反しています。 ioctl() については allow_ioctl でチェックして いるので、 open(pathname, 3) の場合には allow_read/write をチェックしない ように改めました。 (12)TOMOYO 本体の所在を security ディレクトリ以下に移動 fs/ ディレクトリから security/ccsecurity/ ディレクトリに移動し、カーネル コンフィグも File systems セクションから Security options セクションに 移動しました。名前も CONFIG_SAKURA CONFIG_TOMOYO CONFIG_SYAORAN から CONFIG_CCSECURITY に変更されました。 サポートしているカーネルバージョンは TOMOYO 1.6.8 と同じです。 バニラカーネル * 2.4.30 〜 2.4.37.5 * 2.6.11.12 〜 2.6.31-rc8 以下のディストリビューション * Fedora 9 (2.6.27.25-78.2.56.fc9) * Fedora 10 (2.6.27.30-170.2.82.fc10) * Fedora 11 (2.6.29.6-217.2.16.fc11) * CentOS 3.9 (2.4.21-60.EL) * CentOS 4.8 (2.6.9-89.0.9.EL) * CentOS 5.3 (2.6.18-128.7.1.el5) * Debian Etch (2.6.18-24etch4) * Debian Lenny (2.6.26-17lenny2) * Ubuntu 6.06 (2.6.15-54.79) * Ubuntu 8.04 (2.6.24-24.59) * Ubuntu 8.10 (2.6.27-14.39) * Ubuntu 9.04 (2.6.28-15.49) * Ubuntu 9.10 (2.6.31-9.29) * OpenSUSE 10.3 (2.6.22.19-0.4) * OpenSUSE 11.0 (2.6.25.20-0.5) * OpenSUSE 11.1 (2.6.27.29-0.1.1) * Vine Linux 4.2 (2.6.16-76.51vl4) * Asianux 2.0 (2.6.9-78.14AXS2) * Asianux 3.0 (2.6.18-53.25AXS3) * Gentoo * Hardened Gentoo * その他(リクエストをいただければ作成します。) コードサイズは合計 17020 行、TOMOYO 1.6.8 と比べて追加が 9812 行、 削除が 11344 行です。この統計を見ての通り、大幅な変更が行われたため、 まだいくつか不具合が残っているかもしれません。ユーザランドツールの調整や ドキュメント( http://tomoyo.sourceforge.jp/1.7/ )の更新も必要ですので、 しばらくはレポジトリを用いたバイナリパッケージのインストールは提供しません。 TOMOYO Linux では、 SELinux や Smack などと共存できることを目指しています。 LSM を用いたセキュリティモジュールのために様々なオブジェクトに対して security フィールドが提供されていますが、 TOMOYO ではほとんど活用していません。 もし、以下のように @@ -1480,6 +1482,10 @@ struct task_struct { /* bitmask of trace recursion */ unsigned long trace_recursion; #endif /* CONFIG_TRACING */ +#ifdef CONFIG_CCSECURITY + struct ccs_domain_info *ccs_domain_info; + u32 ccs_flags; +#endif }; /* Future-safe accessor for struct task_struct's cpus_allowed. */ タスク構造体に2つのメンバーを追加することが許されるのであれば、 TOMOYO は これらの security フィールドをより有効に活用できるモジュール( SELinux や Smack など)に譲ることができます。 TOMOYO 1.x は LSM を使っていないので、 SELinux や Smack や AppArmor などと同時に利用することが可能です。 どうぞご活用ください。 最後に、プロファイルの設定例について示します。 PROFILE_VERSION=20090903 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 } CONFIG はアクセス制御機能の指定です。以下のカテゴリがあります。 file network capability ipc misc カテゴリを指定した設定は、カテゴリを指定しない設定より優先されます。例えば 0-CONFIG={ mode=disabled grant_log=yes reject_log=yes } 0-CONFIG::file={ mode=learning grant_log=yes reject_log=yes } のように指定した場合、 file に関するアクセス制御機能は学習モードに、 それ以外のアクセス制御機能は無効モードに設定されます。 file カテゴリには以下の項目が含まれます。 execute open create unlink mkdir rmdir mkfifo mksock truncate symlink rewrite mkblock mkchar link rename chmod chown chgrp ioctl chroot mount umount pivot_root 項目を指定した設定は、項目を指定しない設定より優先されます。例えば 1-CONFIG::file={ mode=learning grant_log=yes reject_log=yes } 1-CONFIG::file::execute={ mode=enforcing grant_log=yes reject_log=yes } のように指定した場合、プログラムの実行およびドメイン遷移については強制モードに、 それ以外の file に関するアクセス制御機能は学習モードに設定されます。 従来はプログラムの実行可否(およびドメイン遷移)とそれ以外のファイルに対する アクセス(ファイル作成や読み書きなど)可否を MAC_FOR_FILE で指定していたため、 プログラムの実行可否(およびドメイン遷移)とそれ以外のファイルに対するアクセスの モードを個別に設定することができませんでした。しかし、プログラムの実行可否 (およびドメイン遷移)だけを先に強制モードにできるようになったことで、 どのようにドメイン遷移を行わせるかをデザインしてプログラムの実行可否 (およびドメイン遷移)のみを先に確定(強制モードに移行)してから、それ以外の アクセス許可を追加(学習モード)していくことが可能になりました。 そのため、 execute_handler を用いてプログラム実行時のパラメータだけを記録する 用途や、プログラムの実行可否(およびドメイン遷移)だけを制御する用途でも 使えるようになりました。 network カテゴリには以下の項目が含まれます。 inet_udp_bind inet_udp_connect inet_tcp_bind inet_tcp_listen inet_tcp_connect inet_tcp_accept inet_raw_bind inet_raw_connect 例えば 3-CONFIG::network={ mode=enforcing grant_log=yes reject_log=yes } 3-CONFIG::network::inet_tcp_accept={ mode=enforcing grant_log=no reject_log=no } のように指定した場合、 TCP 接続を受け付ける操作に関してはアクセスログを 取得せず、それ以外の操作に関してはアクセスログを取得するという設定になります。 capability カテゴリには以下の項目が含まれます。 inet_tcp_create inet_tcp_listen inet_tcp_connect use_inet_udp use_inet_ip use_route use_packet SYS_MOUNT SYS_UMOUNT SYS_REBOOT SYS_CHROOT SYS_KILL SYS_VHANGUP SYS_TIME SYS_NICE SYS_SETHOSTNAME use_kernel_module create_fifo create_block_dev create_char_dev create_unix_socket SYS_LINK SYS_SYMLINK SYS_RENAME SYS_UNLINK SYS_CHMOD SYS_CHOWN SYS_IOCTL SYS_KEXEC_LOAD SYS_PIVOT_ROOT SYS_PTRACE conceal_mount ipc カテゴリには以下の項目が含まれます。 signal misc カテゴリには以下の項目が含まれます。 env 今日は知世ちゃんの誕生日です。どうぞ TOMOYO の世界をお楽しみください。 :-)