コンテンツにスキップ

Linux Security Modules

出典: フリー百科事典『ウィキペディア(Wikipedia)』

これはこのページの過去の版です。218.43.112.184 (会話) による 2011年1月25日 (火) 00:55個人設定で未設定ならUTC)時点の版 (外部リンク)であり、現在の版とは大きく異なる場合があります。

Linux Security Modules (LSM)はGNU/Linuxシステムにおいて、任意の1つのセキュリティ実装のみをサポートすることを回避し、同時に様々なコンピュータセキュリティモデルをサポートするためLinuxカーネルに追加されたフレームワークである。GNU General Public Licenseの条項に従いライセンスされ、Linuxカーネルバージョン2.6の標準的な機能の一部となっている。AppArmorSELinuxSmackそして TOMOYO Linuxは現在メインライン(メインストリーム)カーネル(リーナス・トーバルズにより管理されるカーネルソースコードツリーで公式のLinuxカーネル)に存在するLSMベースのセキュリティモジュールである。

日本語圏では、Linux Security Moduleと呼称されるケースが散見されるが、正しくはLinux Security Modulesである。

設計

LSMは可能な限り最低限のLinuxカーネルへの変更のみで済むよう、強制アクセス制御をうまく実装するための特定の必要性をすべて提供するよう設計された。LSMはSystrace(en)のようなシステムコールへの干渉(System call interposition)のアプローチを取ることを避ける。なぜならば、そのようなツールはマルチプロセッサシステムにおけるスケーラビリティに欠け、Time-of-check-to-time-of-useTOCTTOU; 確認プロセスから実行プロセスまでの時間差による競合状態)攻撃に脆弱である。代わりにLSMは、ユーザ空間ツールが最終的にinodeタスク制御ブロック (task control blocks, task_struct)のような重要な内部カーネルオブジェクトへアクセスする際のカーネル内のすべての呼び出し箇所に「フック」(モジュールの上位呼び出し)を挿入する。

プロジェクトはメインストリームカーネルへの巨大かつ複雑な変更は避けるため、アクセス制御の問題解決のスコープに限定している。LSMは一般的な「フック」すなわち「上位呼び出し」のメカニズムを意図しているのではなく、オペレーティングシステムレベルの仮想化(en)をサポートするものでもない。

LSMのアクセス制御の目標はシステム監査の問題と非常に近い関連性があるが少し相違点もある。監査はアクセス試行を全てを記録するということを要求する。LSMはそのようなことは実現しない。なぜなら、関係の深い重要なオブジェクトを取得する前にカーネル内の「ショートカット」によりシステムコールを失敗させ、エラーコードを返すあらゆるケースを検知するため、アクセス記録以上にもっと多くのフックを要求するからである。

LSMの設計はUSENIX Security 2002において論文Linux Security Modules: General Security Support for the Linux Kernel(Linux Security Modules: Linuxカーネルにおける標準的なセキュリティサポート)[1]と言う形で発表された。同じカンファレンスにおいて、Using CQUAL for Static Analysis of Authorization Hook Placement(フック配置の認容の静的な解析のためのCQUALの使用)[2]という、必要なすべてのフックが実際にカーネルに挿入されたことを検証するカーネルソースコードの静的な自動解析に関する研究論文も発表されている。

歴史

2001年Linuxカーネルサミット(Linux Kernel Developers Summit)において、NSASELinuxをLinuxカーネルバージョン2.5に含めるよう提案した。リーナスはその時点ではSELinuxの統合を拒否した。なぜなら彼は開発中の様々なセキュリティプロジェクトが存在することを知っており、それらは全て異なっているため、セキュリティコミュニティは上位のセキュリティモデルを構築するコンセンサスを今だ形成していなかったためである。代わりにリーナスはセキュリティコミュニティにセキュリティモデルの「モジュール化」を実施するよう要求した。

それに対する返答として、クリスピン・コーワン(Crispin Cowan)はローダブル・カーネル・モジュール(LKM)にアクセス制御を強制するためLSMというLinuxカーネル内部からモジュールへの十分な「フック」(上位呼び出し)を供給する、カーネルのインタフェースを提案した。[3]向こう2年をかけ、LSMの開発は、Immunix Corporationen; AppArmorの開発元だったが、2005年ノベルにより買収された。しかし2007年にはAppArmorの開発者はノベルに解雇させられている。その後Ubuntu開発元のCanonicalが彼らを雇用している。)、NSA、 マカフィーIBMSGIからの大部分の貢献を含み、またこれら企業と多くの独立した貢献者により新たに新設されたLSMコミュニティによって主導された。LSMは最終的にはメインストリームカーネルへの受け入れを承認され、2003年12月にLinuxカーネルバージョン2.6の標準機能の一部として取り込まれた。

2006年、いくつかのカーネル開発者がメインストリームのLinuxカーネルソースツリーにおいてLSMを広範に使用しているモジュールはSELinuxのみであることに気づいた。仮にSELinuxのみがLSMを広範に使用するモジュールならば、LSMの間接的な処理は不要であり、LSMは削除されSELinux自身に取って代わるべきであることは理解され得た。[4][5]しかしながら、メインストリームカーネルツリー外でメンテナンスされ、未だ含まれないその他のLSMモジュールが当時あった。(その時点では、AppArmor、Linux Intrusion Detection System (LIDS)、 FireFlierCIPSOMulti ADMなどが当てはまる。)LSMが存在しなければこれらのメインストリームカーネルツリーへのマージはより困難、もしくは不可能となってしまう。またSELinux開発者の中には、AppArmorが(直接議論には上がっていないが、TOMOYO Linuxも当てはまる)ファイルパス名ベースのアクセス制御であることに対し、ラベルベースのアクセス制御であるSELinuxの方が「ファイルなどという常にコロコロ変わるものをベースにする実装より厳密かつ優位に立つ」と主張する者もいた。この議論は2つの結果にたどり着いた。

  1. これらのモジュールの開発者は各自のモジュールをメインストリームカーネルに統合できるよう努力し始めた。
  2. 2006年のカーネルサミットにおいてリーナスは今後もLSMを存置することを再度主張した。彼は最善のセキュリティモデルが何であるかといった議論の仲裁などしたくなかったからである。

これによりもう一つの追加のセキュリティモジュールであるTOMOYO Linuxが2009年6月、メインラインカーネル バージョン2.6.30に統合されるまでLSMは存続することが出来た。

注意すべきことに、LSMを利用して実装されたセキュリティモジュールはカーネル内に互いに共存できるが、同時実行できない。例えば、SELinuxとTOMOYO Linux(バージョン2)はカーネルコンフィグレーションで両方をYesに選択、カーネル内に両者をリンクできるが、実行時にはどちらか一方のみしか有効化することができず、またその方法は起動時のカーネルパラメータにどのセキュリティモジュールを使用するか指定することとなる。(カーネルコンフィグレーションにて、自動的に有効化するセキュリティモジュールを選択することもできる。)Linuxカーネルバージョン2.6.24以前は、上述のとおり完全な強制アクセス制御を持つセキュリティモジュールをLKMとして実装可能だったが、このバージョン以降、特殊な回避方法を用いない限り、LKMとしてはセキュリティモジュールを実装できなくなった。(通常はセキュリティモジュールをカーネルに静的にリンクする必要がある。)そのような特殊な回避方法を用いたモジュールにTOMOYO Linuxの開発者である半田哲夫が作成したAKARIがある。

批判

いくつかのLinuxカーネル開発者はLSMを様々な理由で嫌っている。LSMは、とりわけモジュールが何もロードされない場合において、可能な限りオーバーヘッドを最小限に留めようとするが、そのコストはゼロではなく、この点にいくつかのLinux開発者は反感を持っている。現時点ではLSMはアクセス制御機能提供のためのみに設計されているが、その他の利用方法でLSMを使用することを実際には妨げてはいない。そのため、他の使用目的により「乱用」される可能性、とりわけ、通常はカーネルへのアクセス可能な機能が限定されている、GPLでライセンスされてないプロプライエタリなモジュールがそれらにアクセスする目的でLSMを使いバイパスすることが出来てしまう点をいくつかのLinuxカーネル開発者は嫌っている。

いくつかのコンピュータセキュリティ技術者も同様にLSMを嫌っている。grsecurityの作者は歴史的な理由もあり、次のような理由でLSMを嫌悪している。LSMは必要とするすべてのシンボルをエクスポートするが、この中にはセキュリティモジュールと同様の処理でルートキットのような有害なモジュールの挿入を許すことにつながるものがある。[6]RSBAC(en)の作者もRSBACが必要とするものに対してLSMが不完全であるため嫌っている。とりわけRSBACの作者は次のような主張をしている。「LSMは追加的、制限的アクセス制御のみが実装されているが、RSBACシステムは多くの追加機能を提供する。例えば、シンボリックリンクリダイレクション、secure_delete、Linuxの部分的任意アクセス制御無効化機能がそれに当たる。これらは全てRSBACプロジェクト独自のパッチによりカーネルの機能追加を行わなければならない。」[7]Dazuko(en)の作者は次のような主張をしていた。メインラインカーネルツリーに未だ取り込まれず、ツリー外部におけるメンテナンス作業をする限り、LSMのAPIを実装目標とすることは、常にそのターゲットが変化することに等しい。なぜならLSMに限らずカーネルのAPIはリリースの度に変化するからである。[8]とはいえ、これはリーナスが管理するメインストリームカーネルツリーに含まれない全てのカーネルモジュール、デバイスドライバにも当てはまる話である。ちなみにDazukoはAvira AntiVir開発元のドイツAvira GmbH社が開発し、ファイルシステムスキャンの名目でファイルシステムへのアクセス制御を行うデバイスドライバである。このドライバを使用すると、ファイルシステムのロギングモニタリングを行うことが可能となる。同社のAvira AntiVirのLinuxバージョンをインストールすると同時に導入される。Dazuko自体はBSDライセンスによるオープンソースソフトウェアであり、ソースコードのアクセスは確保されている。[9]バージョン2まではデバイスドライバであったが、ファイルシステムへのアクセスのみを行うことから、バージョン3以降からは完全なファイルシステム(DazukoFS - オンラインファイルアクセスコントロールを行うためのスタック可能なファイルシステム)となっている。いずれのバージョンもLSMを直接利用していない。バージョン3はLSM挿入済みのLinux VFSを使用していることから間接的にはLSMを使用していることになるが、それは「LSMの上に実装するセキュリティモジュール」という意味を成さず、Linuxでサポートされているその他のファイルシステムと全く同等であるという意味しかない。

脚注

  1. ^ Linux Security Modules: General Security Support for the Linux Kernel” (2002年). 2007年2月3日閲覧。
  2. ^ Using CQUAL for Static Analysis of Authorization Hook Placement” (2002年). 2007年2月3日閲覧。
  3. ^ Crispin Cowan (2001年4月11日). “Linux Security Module Interface”. linux-kernel mailing list. 2007年2月3日閲覧。
  4. ^ James Morris (2006年4月17日). “Time to remove LSM”. linux-kernel mailing list. 2011年1月25日閲覧。
  5. ^ Linux Security Module は不要なのか?”. スラッシュドット・ジャパン (2006年4月19日). 2011年1月25日閲覧。
  6. ^ "grsecurity - Why doesn't grsecurity use LSM?" 等”. grsecurity. 2007年2月3日閲覧。
  7. ^ RSBAC and LSM”. RSBAC. 2007年2月3日閲覧。
  8. ^ 2.10 What are the known issues with the LSM (Linux Security Modules) system?”. dazuko. 2007年10月2日閲覧。
  9. ^ Dazuko - A Stackable Filesystem to Allow Online File Access Control”. dazuko. 2011年1月25日閲覧。

関連項目

外部リンク