Tetsuo Handa
from-****@I-lov*****
2010年 10月 10日 (日) 19:19:52 JST
AKARI （ http://akari.sourceforge.jp/ ）は Linux 2.6 カーネル向けのアクセス 解析／制限モジュールです。現在開発中の TOMOYO 1.8 をベースに、純粋にローダブル カーネルモジュール（ＬＫＭ）として追加可能なＬＳＭモジュールに改造しました。 TOMOYO 1.7.2 で対応したようなフックだけをカーネル本体に埋め込んで残りをＬＫＭ として切り離すという方法ではなく、カーネル本体に対する修正を全く必要としない 方法で実現されています。そのため、ＬＳＭがサポートされているカーネルであれば、 AKARI を使うことが可能です。つまり、少なくとも Red Hat Enterprise Linux (RHEL4(2.6.9)/RHEL5(2.6.18)/RHEL6(2.6.32)) Fedora (from Fedora Core 2(2.6.5) to Fedora 14(2.6.36)) Ubuntu (from Warty(2.6.8) to Maverick(2.6.35)) Debian (Sarge(2.6.8)/Etch(2.6.18)/Lenny(2.6.26)/Squeeze(2.6.32)) openSUSE (from 9.1(2.6.4) to 11.3(2.6.34)) などで利用可能です。（カーネルがＬＳＭをサポートしていない場合は使えません。 また、ディストリビュータ独自のパッチが適用されていることにより使えない場合も あることをご了承ください。） AKARI はＬＫＭからアクセスできない関数や変数に強引にアクセスするために、 バイナリコードをスキャンします。そのため、動作しないＣＰＵアーキテクチャが あるかと思います。現時点では x86_32 での動作を確認していますが、 x86_64 や IA64 などの他の環境での動作は確認していません（あるいは確認するための環境を 持っていません）。 このような手法を採用するに至った背景については８月にボストンで開催された Linux Security Summit のライトニングトークで紹介しましたが、参加していない人は 全然知らないでしょうからこのメールの末尾に書きます。 AKARI はカーネル本体に対する修正を全く必要としないため、 TOMOYO 1.8 と比べて 導入のための心理的障壁が低くなっています。また、ネットワーク（送信系操作）の 制限やアクセスログ機能などもサポートされており、 TOMOYO 2.3 と比べてより多くの 機能を利用することができます。そして、 AKARI はＬＳＭモジュールではありますが、 TOMOYO 1.x と同様に他のＬＳＭモジュールとの併用が可能です。 AKARI を使うために SELinux/Smack/TOMOYO/AppArmor などを無効にする必要はありません。 カーネル本体に手を加えないで実現できる範囲で実装しているため、ＬＳＭフックが 提供されていないことにより AKARI では利用できない機能もあります。例えば、 ネットワーク（受信系操作）とシグナル送信とケイパビリティに対する制限には 対応していません。また、ファイルに関するアクセス制御についてもカーネルの バージョンおよびカーネルコンフィグにより、チェック対象となるパーミッションや パス名に対する差異が存在しています。アクセス解析ツールとして使う分には 気にならないと思いますが、アクセス制限ツールとして使うには不十分な部分が あるかと思います。 このようなモジュールを作ることになった背景： 今年の３月頃だったと思いますが、ある人から RHEL4/5 ユーザ向けに単機能な アクセス制御モジュールを作ってほしいという相談を受けました。その際、 TOMOYO 1.x のようにカーネル本体を置き換える方法は利用者にとって心理的な障壁が 高すぎるので、ＬＫＭとして追加可能な方法で実現してほしいと頼まれました。 ＬＫＭであっても RedHat がサポートしていないＬＫＭをロードした時点で RedHat によるサポートを受けられなくなるので、実際にはカーネル本体を置き換えるのと 大差ないと私は思うのですが、エンドユーザはそうは思わないようです。 ご存じの通り、カーネル本体を置き換えずにアクセス制御モジュールを使いたい場合 ＬＳＭを使うしか方法がありません。しかし、カーネル 2.6.24 において、 ＬＳＭモジュールを登録するための関数である register_security() およびＬＳＭ モジュールを呼び出すための変数である security_ops にＬＫＭからアクセスする ことができなくなりました（ http://lkml.org/lkml/2007/7/14/91 ）。 カーネル 2.6.24 以降、表向きにはＬＳＭモジュールをＬＫＭとして実装することは 不可能になりましたが、抜け道として /proc/kallsyms から register_security() の アドレスを割り出すことによりＬＳＭモジュールをＬＫＭとして実装することは 可能でした。しかし、カーネル 2.6.35 において register_security() 自身が initramfs/initrd の開始前に消滅するようになってしまったため、この抜け道も 使えなくなりました（ http://lkml.org/lkml/2010/2/26/239 ）。 これらの仕様変更は RHEL4/5 向けのアクセス制御モジュールを作る上では問題には なりません。しかし、 RHEL6 や Ubuntu 10.10 向けのアクセス制御モジュールを 作る上では大問題です。 どうやってこの問題を解決すれば良いのでしょう？単機能アクセス制御モジュールを ＬＳＭモジュールとして実装してメインラインにマージさせ、それから ディストリビュータに採用を働きかければ良いのでしょうか？ 残念ながら、この方法はうまくいかないのです。 カーネル 2.6.36 へ向けて Yama という単機能ＬＳＭモジュールが提案されましたが マージされませんでした。ＬＳＭは排他的であるゆえ、一通りの基本的な機能を カバーしていないＬＳＭモジュールはメインラインには採用しない方針だからです （ http://lkml.org/lkml/2010/8/3/464 http://lkml.org/lkml/2010/8/5/147 ）。 つまり、 Yama のように単機能なアクセス制御機能を掻き集めただけのＬＳＭ モジュールでは採用されないのです（ http://lkml.org/lkml/2010/8/2/188 ）。 initramfs/initrd 開始後にＬＳＭモジュールをロードすることができないという 制約と、単機能ＬＳＭモジュールはメインラインには採用されないという制約、 ディストリビュータはメインラインに採用されていないコードを採用したがらない という傾向が重なった結果、単機能ＬＳＭモジュールを導入したいユーザに対して 「カーネルを再コンパイルして置き換えるか、さもなくばそのモジュールの導入を 諦めるか」の二者択一を迫らざるをえないという状況が生じているわけです。 （ Yama は例外で、 Ubuntu 10.10 のカーネルには組み込まれています。しかも、 Ubuntu 10.10 のカーネルに組み込まれている Yama はＬＳＭフックではなく独自 フックを利用しているため、 AppArmor や TOMOYO など他のＬＳＭモジュールと 同時に使用することができます。） 「メインラインに入っていないＬＳＭモジュールにはＬＳＭを使わせない」実装に しておきながら、「メインラインに入れるのに値しないＬＳＭモジュールはマージ しない」と規制しているわけです。「メインラインに入っているＬＫＭを利用する 手段は提供するが、メインラインに入っていないＬＫＭを利用する手段は提供 しない」と言っているのに等しいのです。これではＬＫＭやＬＳＭモジュールを 開発・利用する自由を剥奪してしまうことになります。 エンドユーザの自己責任でメインラインに入っていないＬＫＭやＬＳＭモジュールを 利用する自由は認められるべきだと私は思います。それ故、私はＬＫＭからＬＳＭに 強引にアクセスする手法を確立し、ＬＫＭベースのＬＳＭモジュールとして公開した わけです。今まで何処にも無かったものが、ここに誕生しました。 AKARI のソースコードをテンプレートとして使うことにより任意の単機能ＬＳＭ モジュールを開発することができるはずです。 Linux Security Summit では TOMOYO 2.3 を有効にしたまま Yama も有効にするというデモを見せました （ http://www.youtube.com/watch?v=wG8BTLMu5wo ）。また、特定のユーザＩＤ によるソケット操作を全て遮断するというＬＳＭモジュールもあります （ http://kerneltrap.org/mailarchive/linux-netdev/2010/8/26/6283942 ）。
TOMOYO
Fork