Tetsuo Handa
from-****@I-lov*****
2008年 10月 29日 (水) 21:57:47 JST
TOMOYO
Fork 熊猫です。
２００８／１１／１１で TOMOYO Linux 公開から３周年を迎えます。
TOMOYO Linux 1.6.5 のリリースへ向けて仕上げフェーズに入ろうと思いますので、
1.6.4 からの変更点をお知らせします。
カーネルに関して
(1) パス名を扱わないアクセス許可の if 節で task.state を指定できなかったのを
修正しました。
allow_network TCP connect 10.0.0.1 80 if task.state[0]=100 のように
パス名を扱わないアクセス許可の if 節で task.state を指定した場合、
そのアクセス許可が常に無視されてしまっていたのを修正しました。
(2) 一度 /proc/ccs/ への書き込みが許可されたら、そのプロセスがプログラムの
実行を試みるまで /proc/ccs/ への書き込み可否をチェックしないようにしました。
遅延執行モードは、ソフトウェアのアップデートにより発生した突発的な要求を
処理するために導入され、遅延執行モードを扱うためのプログラムとして
ccs-queryd が開発されました。
通常、 ccs-queryd は /proc/ccs/manager にパス名の形式で登録されています。
しかし、 rpm や deb 形式で ccs-tools パッケージを管理するようになった現在、
rpm や dpkg コマンドを用いて ccs-tools パッケージをアップデートする際に
（ロールバックができるようにするために）実行中の ccs-queryd のパス名が
一時的に別の名前に変更されてしまうため、その間は /proc/ccs/ への書き込みが
拒否されてしまう可能性がありました。
ソフトウェアのアップデートの際の突発的な要求を処理するのが目的なのに、
ソフトウェアのアップデートを扱うプログラム（ rpm や dpkg ）の仕様により
ccs-queryd が突発的な要求を処理できなくなってしまっては意味がありません。
そこで、一度 /proc/ccs/ への書き込みが許可されたプロセスは、プログラムの
実行を試みるまで常に /proc/ccs/ への書き込みを許可するようにしました。
この仕様変更により、 ccs-queryd の名前が rpm や dpkg コマンドにより
変更されても目的を果たせるようになります。
副作用として、 /proc/ccs/manager からエントリを削除しても、
一度 /proc/ccs/ への書き込みが許可されたプロセスに対する許可を
剥奪できなくなるわけですが、パス名が変化することで ccs-queryd が
機能しなくなるよりかはマシな筈です。
(3) 遅延執行モードに対して、「許可／拒否」以外に「再試行」という応答を
返せるようにしました。
1.6.4 までの遅延執行モードでは、ポリシー違反が発生した場合に、
ccs-queryd 経由でポリシー違反を無視して先に進ませることはできても、
ポリシー違反が発生した処理を最初からやり直すことはできませんでした。
例えば Java のように、バージョン毎に異なるディレクトリにインストールされる
アプリケーションがあります。ドメイン名の中にバージョンを含むパス名を
使用すると、バージョンアップされた場合にドメイン名ごと修正する必要が
発生してしまいます。そこで、例外ポリシーで
alias /usr/java/j2sdkバージョン/bin/java /usr/bin/java
のように指定することでドメイン名の中にバージョンが含まれないように
工夫することができるわけですが、この方法には欠点があります。それは、
バージョンアップされた時に alias の指定を更新してやらなければいけない
点です。
TOMOYO Linux におけるプログラムの実行処理は幾つものステージに
分割されていますが、最初に alias と一致するかどうかを検査してから
allow_execute と一致するかどうかの検査が行われます。
そのため、 allow_execute の検査を行う時点で alias を更新しても
反映されないため、 /usr/bin/java として処理するには手遅れとなって
しまっていました。
そこで、 1.6.5 の遅延執行モードでは、ポリシー違反が発生した場合に、
ポリシー違反が発生した処理を最初からやり直すことができるようにしました。
ccs-queryd がポリシー違反を報告してきた場合、その間に ccs-editpolicy を
使って alias を更新し、 ccs-queryd に対して「再試行」という返事をすることで
更新された alias が参照されるので、 /usr/bin/java として処理が再開される
ようになります。
また、何回目の「再試行」かを /proc/ccs/query から取得できるログに
含めるようにしました。１回目のポリシー違反の場合は、パス名の変化に起因する
ものかどうかを判断し、自動的に更新して「再試行」させるようにしたかったの
ですが、ちょっと時間が足りません。ですので、 1.6.5 では「再試行」機能だけ
搭載し、ツール側で自動更新する機能の搭載は今後の課題にしたいと思います。
(4) /proc/ccs/.process_status 経由でプロセスの情報を取得できるように
しました。
1.6.4 まではプロセスの task.state を出力するインタフェースが
ありませんでした。
1.6.5 では、「 info プロセスID 」というコマンドを書き込むことで、
指定されたプロセスの task.state を取得することができるようになります。
execute_handler として使われるプログラムが本当に execute_handler として
起動されたかどうかを確認するためのインタフェースも兼ねています。
(5) /proc/ccs/domain_policy でプロセス ID を指定してドメインを選択したり、
特定のドメインだけ読みだしたりできるようにしました。
これは、特定のプロセスが属しているドメインのポリシーだけを参照したい場合に
使うショートカットです。
「 select PID=プロセスID 」または「 select domain=ドメイン名」という
コマンドを書き込むことで、指定されたプロセスまたはドメイン名の
ポリシーだけを読み書きできるようになります。
1.6.4 までは既に削除されたドメインのプロファイル番号を変更する手段が
無かったため、既に削除されたドメインに属しているプロセスの
アクセス制御レベルを変更するには ccs-setlevel を使う必要がありました。
1.6.5 では「 select PID=プロセスID 」というコマンドを使うことで
既に削除されたドメインであってもプロファイル番号を変更できます。
(6) 「アクセス許可ログ」が正確になります。
アクセス許可で ; set task.state 節を指定した場合、 1.6.4 までの
アクセス許可ログには ; set task.state 節を処理した後の値が
記録されていました。
1.6.5 では、 ; set task.state 節を処理する前の値が記録されます。
(7) プログラム実行時にドメイン遷移のロールバックが発生しないようにしました。
TOMOYO Linux はタスク構造体の性質を活かすために、
１個のプロセスに対して２個の独自フィールドを割り当てて利用しています。
メインライン提案用として開発されている TOMOYO Linux 2.2 では
タスク構造体に独自フィールドを追加せずに実現するようにしていました。
幸い、カーネル 2.6.28 まではタスク構造体に security フィールドが
割り当てられていたため、タスク構造体の security フィールドを独占利用する
ことが可能でした。そのため、この security フィールドにドメイン情報を
格納するようにし、プログラム実行時のインタプリタの権限をチェックする際には
遷移先のドメインへと進んでからチェックし、プログラムの実行処理が
失敗した際には遷移元のドメインへと戻るようにしていました。
おそらくカーネル 2.6.29 で採用されるであろう Copy on write credentials
により、タスク構造体から security フィールドが分離され、１個の security
フィールドを複数のプロセス間で共有するように仕様が変更されてしまうことが
確実視されています。 credentials が導入されてしまうと、タスク構造体の
security フィールドの独占利用が不可能となるため、プログラム実行時の
インタプリタの権限をチェックするために遷移先のドメインへと進むことが
できなくなる（つまり、従来の手法が使えなくなる）ことが判明しました。
TOMOYO Linux 2.x では、プログラム実行時のインタプリタの権限をチェックする
際に、予めキャッシュしておいた遷移先ドメインの情報を利用することで、
プログラムの実行処理が成功するまでドメイン遷移が発生しないように修正しました。
TOMOYO Linux 1.x では独自フィールドを割り当てているので関係ない話では
ありますが、今後 1.6 のコードを 2.2 へコピーしやすくするために、
1.6 に関しても遷移先ドメインの情報をキャッシュするように変更し、
プログラムの実行処理が成功するまでドメイン遷移が発生しないように修正しました。
(8) リストを参照する際に参照順序を保証するようにしました。
普通の CPU では A → B の順番に参照するようにプログラムされていれば
A → B の順番に参照されます。しかし、 DEC Alpha アーキテクチャにおいては、
読み込み準備ができたものから読み込むという最適化により参照順序が
逆転することでクラッシュする可能性があることが判明しました。
対策として、リストを参照する際に rcu_dereference() を使うようにしました。
(9) その他クリーンアップ
(7) とも関連するものですが、 1.6 のコードを 2.2 へと
コピーしやすくするために、関数の引数を構造体で渡すようにしたり、
リストに対する更新操作を局所化して不要になったロックを廃止するなどの
クリーンアップを行いました。
(10) カーネル 2.6.27 および 2.6.28-rc2 に対応しました。
ツールに関して
(1) ポリシーファイルの分割に対応しました。
1.6.4 までのポリシーファイルは /etc/ccs/\*.conf だけでしたが、
1.6.5 では /etc/ccs/\*.base と /etc/ccs/\*.conf に分割できるように
なります。
前者はベースとなるポリシーを保持しており、読み込み専用として利用します。
後者はベースに対する差分だけを保持しており、読み書き用として利用します。
互換性のために、前者は作成しなくても大丈夫なようになっています。
これにより、ディストリビュータが出来合いのポリシーを配布しやすく
なるはずです。
(2) ccs-editpolicy の表示方法が変わりました。
従来はディレクティブとオペランドの間のスペースは１個でしたが、
最も長いディレクティブの長さに揃えるようにしました。
これにより、以下のように表示が見やすくなるはずです。
1.6.4 までの表示方法
allow_create /tmp/file
allow_read/write /tmp/file
allow_unlink /tmp/file
1.6.5 での表示方法
allow_create /tmp/file
allow_read/write /tmp/file
allow_unlink /tmp/file
ネットワークに関するディレクティブ名は長く、最も長いディレクティブの長さに
揃えると間が抜けてしまうため、 ccstools.conf で
editpolicy.keyword_alias allow_network RAW bind = allow_network RAW bind
editpolicy.keyword_alias allow_network RAW connect = allow_network RAW connect
editpolicy.keyword_alias allow_network TCP accept = allow_network TCP accept
editpolicy.keyword_alias allow_network TCP bind = allow_network TCP bind
editpolicy.keyword_alias allow_network TCP connect = allow_network TCP connect
editpolicy.keyword_alias allow_network TCP listen = allow_network TCP listen
editpolicy.keyword_alias allow_network UDP bind = allow_network UDP bind
editpolicy.keyword_alias allow_network UDP connect = allow_network UDP connect
のように個別に指定していた別名指定を
editpolicy.keyword_alias allow_network = allow_network
のように１個にまとめることで、間が抜けた表示になるのを防ぐようにしました。
(3) ccs-editpolicy の O ボタン（ Optimize コマンド）を用いて、
カーソル行の address_group または IPv6 アドレスに包含されるエントリを
計算する処理の中で、終了アドレスが無視されていたのを修正しました。
(4) コーディングスタイルのアップデートを行いました。
ccs-patch パッケージに含まれる C プログラムだけでなく
ccs-tools パッケージに含まれる C プログラムも含めて
すべてが scripts/checkpatch.pl によるテストをクリアできるようになりました。
(5) convert-exec-param が exec.argc=0 のログを処理できなかったのを
修正しました。
(6) その他、細かい修正を行いました。
熊猫は１１／１２か１１／１３の PacSec2008 への準備が、
原田さんと武田さんは１１／２１の FreedomHEC Taipei への準備が入っているので
リソースがちょっと不足しています。
試験環境を用意できる方は動作テストをしていただけると嬉しいです。