Toshiharu Harada
harad****@gmail*****
2008年 4月 20日 (日) 15:39:48 JST
原田です。こんにちは。 ELC2008に参加していた2008/4/14にLWN.netにJonathanの書いた件名の タイトルを持つ記事が掲載されました。TOMOYO Linuxのメインライン化に 深い影響を持つためここに日本語訳をつけて紹介します。 オリジナルの記事は、下記で参照できます。1つめのリンクが開けない場合は 2つめで参照ください。この記事を書いたJonathanはTOMOYO Linuxの 最初の海外での発表になったELC2007でTOMOYO Linuxの発表を聞きに きてくれました。今もそのときの驚きを覚えています。今回この記事を 日本語に訳してみて、単なるレポート以上のもの、期待を感じました。 その期待に応えたいと思います。 http://lwn.net/Articles/277833/ http://lwn.net/SubscriberLink/277833/20faea932562b2aa/ -- 8< -- 8< -- "TOMOYO Linux and pathanme-based security" by Jonathan Corbert 「TOMOYO Linuxとpaname方式のセキュリティ」 It takes a certain kind of courage to head down a road when one can plainly see the unpleasant fate which befell those who went before. So one might think that the fate of AppArmor would deter others from following a similar path. The developers of TOMOYO Linux(*1) are not easily put off, though. Despite having a security subsystem which shares a number of features with AppArmor, these developers are pushing forward in an attempt to get their code into the mainline. かつて同じ道を歩んだものが不愉快な結末を迎えているとき、その同じ道を歩むことには ある種の勇気が必要だ。だから、AppArmorの件はあとで同じ道を歩もうとするものを 思いとどませるだろうと考えただろう。しかし、TOMOYO Linuxの開発者達は簡単には 追い払えない。AppArmorと共通する多くの機能を持つセキュリティサブシステムで あるにもかかわらず、彼らは自分たちのコードをメインラインにいれようとしている。 AppArmor, remember, is a Linux security module which uses pathnames to make security decisions. So it is entirely conceivable that two different security policies could apply to the same file if that file is accessed by way of two different names. This approach helps make AppArmor easier to administer than SELinux, but it has given AppArmor major problems in the review process for a few reasons: AppArmorについて思い出してみよう。それは、pathnameを要素としてセキュリティの 判断を行うLinuxのセキュリティモジュールだ。容易に思いつくことは、2つ（以上）の 「名前」によりアクセスされるファイルについては、2つ（以上）の異なるセキュリティ ポリシーが適用されることだ。pathnameを用いるというアプローチはAppArmorを SELinuxより容易に習熟できるものにすることに貢献しているが、コードのレビュー時に いくつかの重要な（方式上の）問題点を指摘されている。 There has been strong resistance to the addition of any new security modules at all, to the point that proposals to remove the LSM framework altogether have been floated. そもそも新しいセキュリティモジュールの追加自体について強い抵抗が存在し続け、 LSMフレークワークを取り除いてしまうという提案すら行われた。 Some security developers see a pathname-based mechanism as being fundamentally insecure. SELinux developers, in particular, have been very strongly against pathname-based security. To these developers, security policies should apply directly to objects (or to labels attached directly to objects) rather than to names given to objects. あるセキュリティ関連の開発者達は、pathnameに基づく機構は、根本的に セキュリティ上欠陥があると見ている。その中でもSELinuxの開発者は、 pathnameに基づくセキュリティに非常に強く反対している。彼らにとって、 セキュリティポリシーとは、それらオブジェクトへの「名前」に対してではなく、 オブジェクト（あるいはそれらオブジェクトに割り当てられたラベル）に対して 適用されるべきものだ。 The current Linux security module hooks, not being developed with pathname-based security in mind, do not provide sufficient information to the low-level file operation hooks. So AppArmor had to reconstruct pathnames within its security hooks. The method chosen for this reconstruction was, one might say, not universally admired. If the TOMOYO Linux developers are serious about getting their code into the mainline, they will need to have answers to these objections. 現行のLSMのフックは、pathnameの利用について考慮しておらず、pathnameを 用いたセキュリティシステムで必要な低レベルのフックを備えていない。だから、 AppArmorは彼ら自身が提案するパッチの中でそのフックを用意しなければならなかった。 その方法は、どうもあまり評判が良くなかった。もし、TOMOYO Linuxの開発者達が、 本気で彼らのコードをメインラインにいれようとするなら、彼らはこれらの（同じ） 反対に対する答えを持つ必要がある。 As it happens, the first two obstructions have mostly gone away. Casey Schaufler's persistence finally resulted in the merging of the SMACK security module for 2.6.25; it is the only such module, other than SELinux, ever to get into the mainline. Now that SMACK has paved the way, talk of removing the LSM framework (which had been strongly vetoed by Linus in any case) has ended and the next security module should have an easier time of it. 偶然にも最初の2つの障害はほとんど消えてしまった。Casey Schauflerの執念 （的な活動）はついにSMACKを2.6.26のモジュールにマージさせた。それは、 かつてSELinux以外でマージされた唯一のモジュールである。SMACKが道を 開いた以上、LSMフレームワークを取り去るという議論は終わった（いずれにしても それはLinusが強力に否定していたが）。そして次のセキュリティモジュールは SMACKよりはやりやすいだろう。 Linus has also decreed that pathname-based security modules are entirely acceptable for inclusion into the kernel. So, while some developers remain highly skeptical of this approach, their skepticism cannot, on its own, be used as a reason to keep a pathname-based security module out. Pathname-based approaches appear to be "secure enough" for a number of applications, and there are some advantages(*2) to using that approach. Linusはpathnameに基づくセキュリティモジュールをカーネルにいれることは全く 問題ないとの見解を示している。だから、ある開発者達が、pathanmeに基づく セキュリティについて、今も深く懐疑的であったとしてもpathnameであることだけが 採用しない理由にはならない。pathnameに基づくアプローチは、多くの アプリケーションにとっては許容範囲（セキュリティ上問題ない）ことがわかっており、 その方法の利点も存在する。 All of the above is moot, though, if the TOMOYO Linux developers are unable to implement pathname-based access control in a way which passes muster(*3). The recent TOMOYO Linux patch took a different approach to this problem: since the LSM hooks do not provide the needed information, the developers just added a new set of hooks, outside of LSM, for use by TOMOYO Linux. And, while they were at it, they added new hooks at all enforcement points. This was not a popular decision, to say the least. The whole idea behind LSM was to have a single set of hooks for all security modules; if every module now adds its own set of hooks, that purpose will have been defeated and the kernel will turn into a big mess of security hooks. Duplicating the LSM framework is not the way to get a security module into the mainline. しかし、もし、TOMOYO Linuxの開発者達が合格レベルのpathnameに基づく アクセス制御を実装することができなければ、これらすべてのことはまだ議論の 余地がある。最近のTOMOYO Linuxのパッチはここで述べた課題、LSMに 必要なフックがない、について「TOMOYO Linuxがが使うためのフックの セットをLSM以外に作る」という方法をとった。そして、その際にエンフォース （制御）を行う場所に新しいフックを追加した。これは少なくとも あまり一般的に行われる判断ではない。LSMの背後にある考えは、 セキュリティモジュールに対してして単一のフックセットを提供するということだ。 もし、すべてのモジュールが独自のフックを追加したら、LSMの目的は失われ、 セキュリティフックはゴミためのようになる。LSMフレームワークを複数持つことは セキュリティモジュールがメインラインに入るための道ではない。 So, somehow, the TOMOYO Linux developers will need to implement pathname-based security in a different way. The most obvious thing to do would be to modify the existing hooks to supply the requisite information (being a pointer to the vfsmount structure). The problem here is that, at the point where the LSM hooks are called, that structure is not available; it is only used at the higher levels of the virtual filesystem code. So either some core VFS functions would have to be changed (so the vfsmount pointer could be passed into them), or a new set of hooks would need to be placed at a level where that pointer is available. It appears(*4) that the second approach - adding new hooks in the namespace code - will be taken for the next version of the patch. だから、TOMOYO Linuxの開発者達は、なんとかpathnameに基づくセキュリティを違う 方法で実装しなければならない。もっともわかりやすいのは、既存のフックに 必要な情報（vfsmount構造体へのポインタ）を追加することだろう。その場合の問題点は、 LSMフックが呼ばれた場合、その構造体を参照できないことだ。それはファイル システムの仮想化(VFS)の上位でしか使われていない。なので、主要なVFS関数の いくつかを（vfsmountポインターが渡るように）変えるか、あるいはそのポインターが 見えているところに必要なフックを追加するかの方法が考えられる。2つめの アプローチ、namespaceの部分にフックを追加する、が次のパッチで採用されそうだ。 As the TOMOYO Linux developers work through this problem, they are likely to be closely watched by the (somewhat reduced in number) AppArmor group. There appears to be a resurgence of interest in getting AppArmor merged, so we will probably see AppArmor put forward again in the near future. That will be even more likely if TOMOYO Linux is able to solve the pathname problem in a way which survives review and gets into the kernel. TOMOYO Linuxの開発者達がこの問題の解決に取り組んでいる間、彼らは （規模が縮小した）AppArmorのチームからも注意深く見守られるだろう。 AppArmorの復活への興味も見られるから、我々は将来再びAppArmorの提案を 見ることになるかもしれない。それはTOMOYO Linuxがレビューを生き残れる 方法でpathnameの問題を解決し、カーネルに入ればさらに確実となる。 *1 http://elinux.org/TomoyoLinux *2 http://lwn.net/Articles/277842/ *3 http://lwn.net/Articles/276603/ *4 http://lwn.net/Articles/277846/ -- Toshiharu Harada harad****@gmail*****
TOMOYO
Fork