Toshiharu Harada
harad****@gmail*****
2006年 4月 28日 (金) 01:22:04 JST
NTTデータの原田です。4/24にRussell Coker氏を弊社茅場町に 迎えてTOMOYO Linuxのデモと議論を行いましたが、Russellより 詳しいコメント（提言）をいただきました。 Russellからもらったコメントのメール全文について、即席日本語訳と並べて ご紹介します。なお、Russellが言及している論文は、 http://sourceforge.jp/docman2/ViewCategory.php?group_id=1973&category_id=531&language_id=1 にあるものです。それらの日本語版は、同じところの"Japanese"を選択するか、 http://d.hatena.ne.jp/keyworddiary/TOMOYO%20Linux より参照下さい。kumanekoさんと相談の上回答をしますが、 そちらもご紹介したいと思っています。 SELinuxの部分について間違った解釈をしていればご指摘いただけると 幸いです。 ---------- Forwarded message ---------- From: Russell Coker <russe****@coker*****> Date: 2006/04/27 17:13 Subject: Tomoyo Linux After seeing the demonstration of Tomoyo Linux and reading some of the documentation I have some suggestions. TOMOYO Linuxのデモおよびいくつかのドキュメントを見て、いくつかの 提案があります。 Firstly I suggest that you use the Linux auditing system for event logging. This means that there is some commonality of tools, the auditd that ships with Fedora (and will soon be in Debian) can be used which will save some effort. The following kernel compile options are used to turn this on. The AUDITSYSCALL option is not actually required, but is something that you will probably want. まず、イベントの記録についてはLinuxのauditシステムを使うのが良いと思う。 これは（適用できる）ツールの共通化という意味がある。Fedora（そしてまもなく Debianでも）提供されるauditdを使えば自分で書く部分を減らすことができる。 そのためには以下のカーネルコンパイルオプションをonにする。AUDITSYSCALL オプションは実際には必要ではないが、多分あなたたちが使いたいと思うものだろう。 CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y Of course the AUDIT system requires a 2.6.x kernel (AFAIK it was not available in 2.4.x). This shouldn't be a problem as 2.4.x and 2.6.x have greatly diverged anyway. 勿論AUDITシステムは2.6カーネルでないと使えない（私の知る限りでは 2.4カーネルでは使えなかったはずだ）。2.6は（良い意味において） 2.4とは非常にかけ離れたものになってしまったので、このことは （2.6カーネルを前提とすることは）問題にならないだろう。 Next I suggest using LSM interfaces. If you can entirely use LSM interfaces then Tomoyo can be a candidate for inclusion in kernel.org kernels. 次にLSMに準拠（対応）することを勧める。もしLSMに準拠するように 書き直せば、TOMOYOのパッチはkernel.orgのカーネルツリーに 取り込まれる候補となることができる。 If you mostly use LSM interfaces then you will save a significant amount of development work in terms of maintaining support for new kernels and also save development work for everyone who wants to use your system along with other patches. The divergence between the Debian and Fedora kernels alone is enough to cause a significant amount of work if LSM is not used. もしLSMインタフェースをメインに使用するように修正すれば、今後の新たな カーネルへの対応に必要となる労力を激減できるし、TOMOYOの機能を 取り込もうとする他のパッチの労力についても同様だ。LSMを用いれば(?) DebianカーネルとFedoraカーネルの間の乖離だけが、ちょっとした 作業の対象となる。→LSMに準拠するメリットは承知しているのですが、 そうできない理由があります。それをRussellに説明しきれませんでした。 After those changes I suggest some changes to the core Tomoyo design. The first change I suggest is to have equivalence classes (let's call them domains). This means that "vi" and "emacs" will be considered to have identical security properties, they will have the same access rights and the same domain call chain will be entered for programs that they execute. The same would apply for "bash" and "tcsh", "more" and "less", "sed" and "grep", and many other sets of programs with equivalent functionality. To deny running "emacs" because the machine ran "vi" in learning mode makes no sense. Having two separate domains (taking more RAM) for both the editors is also undesirable. Page 11 of nsf2003-en.pdf seems to support my opinion in this regard. これらの変更の最後に、TOMOYOのコアデザインの変更を提案する。 最初の提案は、同等なクラス（という概念）を持つことだ。（ここではそれらを ドメインと呼ぶことにしよう）これは例えば、"vi"と"emacs"がセキュリティ上は 同じ属性を持ち、同じアクセス権限を持ち、それらが実行するプログラムが 同じドメインにつながれるということだ。"bash"と"tcsh"、"more"と"less"、"sed"と "grep"そして他の多くの等価的な機能を持つプログラム群のセットだ。 あるマシンにおいて"vi"で学習したから（学習していない）"emacs"を拒否するという のは意味がない。（同じような機能を持つ）二つのプログラムのドメインを （それだけ多くのRAMを消費して）持つということは、望ましくない。 NSF2003論文の11ページはこの観点で私の意見を支持している。 →Russellの言っていることはわかりますが、私はそれが利点、あるいは 必要なこととは思えないのです。 Also the paper nsf2003-en.pdf gives no rationale for the lack of circular domain transitions. We don't always want circular transitions, but I believe that they are necessary in some situations. For example the administrator may restart sshd and then login again with the new sshd and repeat this process any number of times. また、NSF2003論文においては、循環するドメイン遷移が存在しないことの 根拠が示されていない。誰も循環するドメイン遷移を欲してはいないが、 いくつかの状況においては避けられないものであると考えている。 例えば、管理者がsshdを再起動し、新たなsshd経由でログインする、 その任意の繰り返しだ。→TOMOYO Linuxではこのような場合は ループとは考えません。あまり考える必要もないように思うのですが。 The paper nsf2003-en.pdf says "access permissions have to be granted as a union for domains that are transited by multiple domains" on page 3. I believe this to be a misunderstanding of the situation. If the multiple domains have significantly different needs then SE Linux policy can be written such that there are multiple child domains. For example the passed_t domain is permitted to access all terminal types. We could easily have written policy for user_passwd_t, staff_passwd_t and sysadm_passwd_t domains that each have only access to the relevant types for devpts and terminal device nodes, however given that the passwd_t domain has read/write access to shadow_t this doesn't seem necessary. NSF2003論文の3ページでは、「複数の呼び出し元から遷移するドメインに対しては、 アクセス許可範囲を和集合として定義する必要がある」とある。 これは状況を誤解しているのではないか？もし複数のドメインが顕著に 異なる要求を持つならSE Linuxのポリシーは複数の子となるドメインとして 書かれるだろう。→もとの論文で言っていることは単純なのですがどうも それがRussellに伝わっていないようです。 それぞれが関連するdevptsとターミナルデバイスノードのみにアクセスできるような user_passwd_t, staff_passwd_t, sysadm_passwd_tのポリシーを書くことは容易だが passwd_tドメインがshadow_tへ読み書きできるようになっていればそれは 必要とは思われない。→この部分解釈が正しいか特に自信ありません。 Page 8 of the paper nsf2003-en.pdf has the script /etc/rc3.d/S85httpd getting write access to the /dev directory, why is that? NSF2003論文の8ページでは、/etc/rc3.d/S85httpdが/devディレクトリに対する 書き込み権限を持っている（必要としている）ことを示しているが何故だ？ →実際に学習した結果のはずですが後で確認 Page 9 of nsf2003-en.pdf seems to be the most effective demonstration of the limitations of the call-chain security model. NSF2003論文の9ページはcall-chainセキュリティモデルの制限を非常に うまく表現している。 The paper winf2005-en.pdf has some pictures of penguins in police uniform on page 2, are there larger pictures of such uniformed penguins? 情報ワークショップ2005の論文の2ページには制服を着たペンギンの絵があるが、 もっと大きな図はないのか？→何故そんなことを聞くのか？ -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- Toshiharu Harada mailto:harad****@gmail*****
TOMOYO
Fork