Tetsuo Handa
from-****@I-lov*****
2009年 10月 6日 (火) 23:24:10 JST
熊猫です。 Hideki Yamane さんは書きました： > では、2.2 のパッケージを現在作成する事の益は、実験目的以外はほとんど無い > （2.6.30-31 での機能が不十分であるため）という理解であっていますか？ はい。 TOMOYO 2.2.0 はバグだらけのゴミです。 Proof of concept demonstration として評価する程度にとどめ、実際のシステムへの適用は避けるべきと考えています。 例えばパス名の取得には d_path() を使っていますが、 d_path() はファイルが 削除済みの場合 (deleted) という文字列を追加します。そのため、 /tmp/foo が open() される→ ftruncate() で切り詰められる→ unlink() で削除されるという シーケンスの場合は allow_write /tmp/foo allow_truncate /tmp/foo allow_unlink /tmp/foo ですが、 /tmp/foo が open() される→ unlink() で削除される→ ftruncate() で 切り詰められるというシーケンスの場合は allow_write /tmp/foo allow_truncate /tmp/foo\040(deleted) allow_unlink /tmp/foo となります。アクセスが許可されるかどうかがファイルが削除されているか否かに 依存しているのです。（ TOMOYO 1.x では依存しません。） また、ＬＳＭのフックはカーネル内部からの open() リクエストに対しても 呼ばれます。幾つかのファイルシステムではファイルシステム自身が open() リクエストを行います。その場合、ユーザランドアプリケーションが要求するパス名と ファイルシステムが要求するパス名の両方を許可する必要が生じます。しかし、 ＬＳＭにはユーザランドアプリケーションが要求したものかどうかを知らせる方法が ありません。つまり、実行時に必要なアクセス許可がファイルシステムのマウント 状況に依存するため、アプリケーション用のポリシーを作成して配布することが できません。（ TOMOYO 1.x ではカーネル内部からの open() リクエストはチェック されないようにフックを挿入しているため、依存しません。） TOMOYO 2.2.0 では自プロセスの情報にアクセスするために /proc/PID/ にアクセス する際に /proc/self/ に変換することができません。多くのアプリケーションは 自分以外のプロセスの情報へのアクセスを必要としません。 /proc/自分自身のPID/ を /proc/self/ に変換する処理は、パス名ベースのアクセス制御でも必要以上の アクセス許可を与えないようにできる数少ないチャンスなのです。 非ＬＳＭ版にもいくつか問題はありますが、ＬＳＭ版は問題だらけです。 これらの問題の内、非ＬＳＭ版であれば回避できる問題のいくつかを解消するために TOMOYO 2.3.0 を２日前に提案しました。
TOMOYO
Fork