2006年4月28日

[selinux-users:01554] RussellからTOMOYO Linuxに関するコメントをもらいました

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
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:haradats@xxxxx

投稿者 xml-rpc : 2006年4月28日 01:22
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/35605
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。