From from-tomoyo-users ＠ I-love.SAKURA.ne.jp Sun Oct 10 19:19:52 2010 From: from-tomoyo-users ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Sun, 10 Oct 2010 19:19:52 +0900 Subject: [Tomoyo-dev 1266] =?iso-2022-jp?b?QUtBUkkgMS4wIBskQiRyJWolaiE8JTkkNyReJDckPyEjGyhC?= Message-ID: <201010101919.BCF95887.FPNSTUGStPtNZTPVP@I-love.SAKURA.ne.jp> 　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 ）。 From from-tomoyo-users ＠ I-love.SAKURA.ne.jp Tue Oct 12 21:10:42 2010 From: from-tomoyo-users ＠ I-love.SAKURA.ne.jp (Tetsuo Handa) Date: Tue, 12 Oct 2010 21:10:42 +0900 Subject: [Tomoyo-dev 1267] =?iso-2022-jp?b?GyRCJU8lOUw+ST01LUp9SyEkTkpROTkkSyREJCQkRhsoQg==?= In-Reply-To: <201009112203.DCH60496.tPSVSNFtNTPGTPPZU@I-love.SAKURA.ne.jp> References: <201009112203.DCH60496.tPSVSNFtNTPGTPPZU@I-love.SAKURA.ne.jp> Message-ID: <201010122110.BAH09382.FPUtTStPTSNPPNVGZ@I-love.SAKURA.ne.jp> 　前回の報告以降の TOMOYO 1.8 に対するユーザの目に見える変更として、ポリシー 違反発生時にポリシー違反メッセージを表示するかどうかを指定する verbose= オプションを廃止しました。代わりに、ポリシー違反の発生状況を確認するために /proc/ccs/stat インタフェースを追加しました。ポリシー違反の有無を /proc/ccs/stat で調べ、ポリシー違反の内容を /proc/ccs/reject_log で調べる という手順です。また、 file_pattern 構文を廃止しました。パス名をワイルドカード 化する処理はカーネルの中では行わず、ユーザ空間で行うようにしました。 　現在、パス名を表記する際に、 / で終わればディレクトリ名、 / 以外で終われば ディレクトリ以外という区別をしています。これは、書き込みアクセスの権限が現在の create write mkdir unlink などのように細分化されていなかった（読み書き実行を それぞれ 4 2 1 で表現していた）頃の名残です。そのため、例えばホームディレクトリ 以下のリネームを許可したい場合に 　file rename /home/\{\*\}/ /home/\{\*\}/ 　file rename /home/\{\*\}/\* /home/\{\*\}/\* のように２つに分けて指定する必要があります。 現在では必要に応じて path1.type=directory などといった条件指定をすることが 可能であるため、末尾の / の有無による区別を廃止して 　file rename /home/\{\*\}/\* /home/\{\*\}/\* のように集約してしまい、例えばディレクトリのリネームを禁止したい場合のみ 　file rename /home/\{\*\}/\* /home/\{\*\}/\* path1.type!=directory path2.type!=directory という条件指定を行うように変更しても構わないのかなと感じています。 副作用として今までディレクトリを指定する際に 　file mkdir /home/\{\*\}/ のように指定できていたものが 　file mkdir /home/\{\*\}/\* のようにベースネーム部分を明示する必要が生じます。 TOMOYO 1.8 でこのように仕様を変更しても容認できますか？この変更に問題がある方は 返信ください。返信が無いようでしたら処理の単純化のために末尾の / の有無による 区別を廃止します。