Shinpei Nakata
shinp****@gmail*****
2009年 6月 11日 (木) 03:32:06 JST
黒猫さん、 nakataです。 早々のお返事、ありがとうございました。 以下、返信させていただきます。 > > いらっしゃいませ〜。 おじゃまします。:) >> ズバリ、セキュリティの観点からいまのSELinuxだと防げなくて、TOMOYOだと >> 防げるという攻撃は存在しますか？？ >> Policy記述さえがんばれば、TOMOYOで実現していることをSELinuxでもできるのでは >> ないかと疑問を持っています。 > > ラベル方式にはパス名方式では実現できない機能（例：ファイルのハードリンクや > 名称変更が生じても一貫した読み書き実行の可否を判断できる）があり、パス名方式 > にはラベル方式では実現できない機能（例：存在してよい名前を制限することで > 想定外の用途で使われたり想定外の振る舞いを生じさせないようにすることができる） > があります。 なるほど。まだ2.6.30のコードをみていないのですが、 この機能はLSMのみで実現できるようにパッチングされたという理解でいいのでしょうか？ （すいません、あとでコードよんでみます！） > > http://lkml.org/lkml/2009/3/26/411 には TOMOYO Linux のマージを決断した > James Morris のコメントがあります。 >> It's also an inherent aspect of pathname security, an issue which >> has been resolved in favour of inclusion in the kernel. > > AppArmor 陣営は、「ラベルとパス名とどちらが簡単か」という主張をしてしまったため > マージされませんでしたが、 TOMOYO 陣営は「パス名にしかできないこともあるんだ」 > という主張を（国際会議などのオフラインイベントを通じて）行ってきたためマージ > されました。もし、ラベル方式がすべての側面でパス名方式よりも勝っていたら、 > TOMOYO Linux がマージされることは無かったでしょう。 なるほど。やはりそうですよね！ >> (Sourceforge上にあがっている資料はすべて目を通しました） > > 最近は英語版の資料 > （ http://sourceforge.jp/projects/tomoyo/docs/?category_id=532&language_id=1 ） > ばかり作っていたので、日本人の間でもほとんど知られていないのですが、 > > 20080510 Why TOMOYO Linux? > http://sourceforge.jp/projects/tomoyo/docs/tlug200805.pdf では > 「オブジェクトにラベルを割り当てることはできるが、オブジェクトの中に > 含まれているバイト列にラベルを割り当てることはできない。オブジェクトの中に > 含まれているバイト列がユーザ空間にコピーされた後、どのように伝播していくかは > ユーザやプログラムの振る舞いに完全に依存している。だから、（カーネル内で > 行われているアクセス制御が）望まない相手へと情報が伝播しないことを証明する > ことは不可能だ。」という主張をしています。 ラベルの割当はLSMの提供するKernel Objectへのvoid *securityポインタ各種が 担当しているかとおもいます。今回、パス名へのラベリングができているのは あらたにKernel Objectへパス名が追加されたのでしょうか？ それとも、パス名を保存しておくなにかが、べつの場所に保存されたのでしょうか？？ > 20080710 The role of "pathname based access control" in security. > http://sourceforge.jp/projects/tomoyo/docs/lfj2008-bof.pdf では > 「ラベルベースのアクセス制御はオブジェクトの名前の変化の影響を受けない > という利点があるが、だからといってオブジェクトの名前の変化を無視することは > 危険である。なぜなら、オブジェクトの名前の変化は、そのオブジェクトがどのように > 使われるか（オブジェクトの中に含まれているバイト列がどのように伝播していくか） > の変化を引き起こす場合があるからである。」という主張をしています。 > 20090120 Deep inside TOMOYO Linux > http://sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf > は「20080710 The role of "pathname based access control" in security.」の内容を > TOMOYO を用いたソリューションとして書き直したものです。 SELinux に不足している > 部分を補う存在としての TOMOYO について紹介しています。 ありがたく資料、拝読させていただきます。 また疑問があれば投げさせていただこうと思います。 > >> 私の研究は複数のLSMを組み合わせてなにができるか考えてみよう。というものなのですが、 > 現時点ではＬＳＭは排他的仕様になっているため、 SELinux や SMACK とＬＳＭ版の > TOMOYO とを組み合わせて使うことができません。 > 非ＬＳＭ版の TOMOYO もありますので、どうぞお試しください。 Stackableをつかわず、現在では独自のLSMから、それぞれのLSMフックにディスパッチする方法を とっています。カーネルオブジェクトのラベルは飛ばす前にスイッチしてるので （まだ実装は終わってませんが）おそらくうごくのかなぁと。。。 返信ありがとうございました。 やはりまずソースをよんでみることにします！ nakata
TOMOYO
Fork