[tomoyo-users 304] TOMOYO Linux 2.1.0/1.4.3 をリリースしました。

Back to archive index

Tetsuo Handa from-****@I-lov*****
2007年 11月 17日 (土) 16:19:36 JST


 熊猫です。

 TOMOYO Linux 2.1.0 は TOMOYO Linux 1.5.1 に搭載されているのとほぼ同じ機能を利用でき、
カーネル 2.6.8 〜 2.6.23 に対応しています。
使い方は http://tomoyo.sourceforge.jp/ja/2.1.x/ です。

 ただし、発生する確率は低いですがデッドロックを引き起こすバグが存在します。
具体的には、マウント/アンマウントなどの操作要求と
その操作が行われるディレクトリ(マウントポイント)に対する
ファイルの作成/削除などの操作要求が同時に発生した場合にデッドロックが発生します。
例えば、あるスレッドが

  mount -t tmpfs none /tmp/

という操作を実行中に、別のスレッドが

  touch /tmp/file

という操作を実行した場合に発生します。

 アクセスが要求されたパス名を導出するためには dentry と vfsmount という
2種類の情報が必要ですが、 TOMOYO 2.x で使用している LSM というフレームワークには
dentry だけしか渡されません。そのため、なんとかして vfsmount を入手する必要があります。
各プロセスは vfsmount のリストを保持しているため、そのリストから vfsmount を入手することはできるのですが、
リストを検索中に内容が変化しないようにするために namespace_sem というロックを取得する必要があり、
上記の mount と touch のような操作が同時に発生するとロックの取得順序が原因でデッドロックに陥ってしまうのです。

 openSUSE 10.1 および 10.2 に搭載されている AppArmor にも同じバグが存在しています。
TOMOYO 2.x は AppArmor のソースコードを見て「 AppArmor でも同じ方法で実現しているからこれで大丈夫なんだな」と
信じてしまったわけですが、11/5になって「この方法ではデッドロックを引き起こす危険性がある」ことが発覚しました。
カーネル開発者のMLで相談してみましたが、「パス名を用いたアクセス制御という設計自体を見直せ」という
従来からの主張以外に対策は提示されませんでした。
TOMOYO 2.x は標準に準拠することを優先しており、カーネル本体への修正は極力避けるという方針であるため、
やむなくデッドロックの可能性がある状態のまま 2.1.0 をリリースすることにしました。

 マウント/アンマウントのような操作は定常状態では発生しないので
このバグに遭遇する可能性は低いと考えていますが、運悪く遭遇してしまったらごめんなさい。

 なお、このバグは、 TOMOYO 1.x には存在しません。
TOMOYO 1.x では vfsmount を渡すために独自のフックを挿入することにより
namespace_sem ロックを取得する必要が無いように実装されているためです。





 また、 1.5.x への移行が困難な方のために、
1.4.2 のバグを修正しただけのものを 1.4.3 としてリリースしました。
既に 1.5.x へ軸足を移動しているため、今後は 1.4.x がリリースされる予定はありません。





 今後は、
(1) 環境変数に対するアクセス制御機能
(2) ポリシーに違反した場合に短時間スリープさせるペナルティ機能
(3) 許可されていないプログラムの実行が要求された時に別のプログラムを実行する機能
を搭載したいと考えています。

 環境変数を使うとプログラムの振る舞いを変えることができますが、中には危険なものもあります。
http://www.linux.or.jp/JF/JFdocs/Secure-Programs-HOWTO/environment-variables.html
そこで、プログラムの実行時に渡すことができる環境変数の名前を
ホワイトリスト形式で制限する機能を搭載したいと思っています。

 攻撃者はプログラムの脆弱性を突いてシェルコードを注入してくるわけですが、
シェルコードの中には成功するまで処理を繰り返すしつこいものもあります。
強制アクセス制御を適用することでシェルの実行を阻止することはできるわけですが、
副作用としてCPU使用率が100%となってしまうために
他の正常なサービスに影響が出るという問題が存在しています。
そのため、ポリシー違反の発生時に短時間スリープさせてやれば、
CPU使用率が100%になるのを回避できます。
もちろん、ポリシー違反にならないような処理(何もしない無限ループ)で
CPU使用率を100%にさせるという攻撃には対処できませんが、
通常はシェルを実行して悪事を働くのが目的であるため、簡単に使えて高い効果があると思います。

 Ubuntu には command-not-found という、ユーザが実行しようとしたコマンドが見つからなかった場合に
どのパッケージをインストールすれば使えるようになるのかを教えてくれる機能があります。
そこで TOMOYO Linux でも、ユーザが許可されていないコマンドの実行を要求した場合に
単に Permission denied というメッセージを出す代わりに
カスタマイズされた処理(詳細な警告を出すなど)を行うための
ポリシー違反ハンドリングプログラムを実行させる機能を搭載したいと思っています。
ommand-not-found の捩りというわけではないのですが、 command-not-permitted みたいなイメージです。
搭載できれば、ログイン認証の多重化みたいにいろいろ面白いことができます。
ちなみに、この機能の本来の用途は、
http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/2007-September/000560.html
http://lists.sourceforge.jp/mailman/archives/tomoyo-dev/2007-September/000563.html
で議論が行われていますが、シェルコードをさっさと強制終了させるためのものです。

 既に実装は済んでいますが、特許侵害に該当しないかどうかの調査を
行う必要があるため搭載時期や搭載できるかどうかは不明です。





 おかげさまで TOMOYO Linux も公開から2周年を迎えました。
コンパイルやパッケージ化に協力していただいたり、イベントのためにポスターを制作いただいたり、
仕様についていろいろとアドバイスをしていただいたりと、いろんなメンバーに助けていただきました。
心から感謝いたします。今後とも応援をよろしくお願いいたします。
--
  熊猫さくら




tomoyo-users メーリングリストの案内
Back to archive index