|
Linux Security Modules
Linux Security Modules (LSM) はGNU/Linux（Linuxディストリビューション）において、任意の1つのセキュリティ実装のみをサポートすることを回避し、同時に様々なコンピュータセキュリティモデルをサポートするためLinuxカーネルに追加されたフレームワークである。GNU General Public Licenseの条項に従いライセンスされ、Linuxカーネルバージョン2.6の標準的な機能の一部となっている。AppArmor、Security-Enhanced Linux (SELinux)、Smackそして TOMOYO Linuxは現在メインライン（メインストリーム）カーネル（リーナス・トーバルズにより管理されるカーネルソースコードツリーで公式のLinuxカーネル）に存在するLSMベースのセキュリティモジュールである。 カーネルソースコードディレクトリのトップにある 名称より誤解を受けることが多いが、2011年現在におけるLSMはローダブル・カーネル・モジュール (LKM) ではなく、カーネル内に静的にリンクされる。またLSMの上に実装される各種セキュリティモジュールは以前はLKMとして実装可能であったが、現在では原則不可能である（後述）。 "Linux Security Module"と呼称する文書・Webページが散見されるが、正しくはLinux Security Modulesである。 設計LSMは、Linuxカーネルへの変更を可能な限り抑えつつ、強制アクセス制御をうまく実装するためのあらゆる機能を提供するという、特定の用途のために設計された。LSMはSystraceのようなシステムコールへの干渉 (System call interposition) のアプローチを取ることを避ける。なぜならば、そのようなツールはマルチプロセッサシステムにおけるスケーラビリティに欠け、Time-of-check-to-time-of-use（TOCTTOU; 確認プロセスから実行プロセスまでの時間差による競合状態）攻撃に脆弱である。代わりにLSMは、ユーザ空間ツールが最終的にinodeやタスク制御ブロック (task control blocks, task_struct) のような重要な内部カーネルオブジェクトにアクセスする際のカーネル内のすべての呼び出し箇所に「フック」（モジュールの上位呼び出し）を挿入する。 プロジェクトはメインストリームカーネルへの巨大かつ複雑な変更は避けるため、アクセス制御の問題解決のスコープに限定している。LSMは一般的な「フック」すなわち「上位呼び出し」のメカニズムを意図しているのではなく、オペレーティングシステムレベルの仮想化をサポートするものでもない。 従来からLinux環境で利用されてきたセキュリティモジュールPluggable authentication module (PAM, Linux PAM) はユーザー認証やパーミッション制御のみに特化しているが、LSMはそれよりもカバーする範囲は広い。 LSMのアクセス制御の目標はシステム監査 (System audit) の問題と非常に近い関連性があるが少し相違点もある。監査はアクセス試行を全てを記録するということを要求する。LSMはそのようなことは実現しない。なぜなら、カーネル内の「ちょっとした回り道」によるシステムコール失敗を検知し、関連する重要オブジェクトが取得される前にエラーコードを返すには、さらに非常に多くのフックが必要となるためである。 LSMの設計はUSENIX Security 2002において論文Linux Security Modules: General Security Support for the Linux Kernel（Linux Security Modules: Linuxカーネルにおける標準的なセキュリティサポート）[1]と言う形で発表された。同じカンファレンスにおいて、Using CQUAL[2] for Static Analysis of Authorization Hook Placement（フック配置の認容の静的な解析のためのCQUALの使用）[3]という、必要なすべてのフックが実際にカーネルに挿入されたことを検証するカーネルソースコードの静的な自動解析に関する研究論文も発表されている。 歴史2001年のLinuxカーネルサミット(Linux Kernel Developers Summit)において、NSAはSecurity-Enhanced Linux (SELinux) をLinuxカーネルバージョン2.5に含めるよう提案した。リーナスはその時点ではSELinuxの統合を拒否した。なぜなら彼は開発中の様々なセキュリティプロジェクトが存在することを知っており、それらは全て異なっているため、セキュリティコミュニティは上位のセキュリティモデルを構築するコンセンサスを未だ形成していなかったためである。代わりにリーナスはセキュリティコミュニティにセキュリティモデルの「モジュール化」を実施するよう要求した。 それに対する返答として、クリスピン・コーワン(Crispin Cowan)はローダブル・カーネル・モジュールにアクセス制御を強制するためLSMというLinuxカーネル内部からモジュールへの十分な「フック」（上位呼び出し）を供給する、カーネルのインタフェースを提案した[4]。向こう2年をかけ、LSMの開発は、Immunix Corporation[注釈 1]、NSA、 マカフィー、IBM、 SGIからの大部分の貢献を含み、またこれら企業と多くの独立した貢献者により新設されたLSMコミュニティによって主導された。LSMは最終的にはメインストリームカーネルへの受け入れを承認され、2003年12月にLinuxカーネルバージョン2.6の標準機能の一部として取り込まれた。 2006年、一部のカーネル開発者がメインストリームのLinuxカーネルソースツリーにおいてLSMを広範に使用しているモジュールはSELinuxのみであることに気づいた。仮にSELinuxのみがLSMを広範に使用するモジュールならば、LSMの間接的な処理は不要であり、LSMは削除されSELinux自身に取って代わるべきであることは理解され得た[5][6]。しかしながら、メインストリームカーネルツリー外でメンテナンスされ、未だ含まれないその他のLSMモジュールが当時あった。（その時点では、AppArmor、Linux Intrusion Detection System (LIDS)、 FireFlier、CIPSO、Multi ADMなどが当てはまる。）LSMが存在しなければこれらのメインストリームカーネルツリーへのマージはより困難、もしくは不可能となってしまう。またSELinux開発者の中には、AppArmorが（直接議論には上がっていないが、TOMOYO Linuxも当てはまる）ファイルパス名ベースのアクセス制御であることに対し、ラベルベースのアクセス制御であるSELinuxの方が「ファイルなどという常にコロコロ変わるものをベースにする実装より厳密かつ優位に立つ」と主張する者もいた。この議論は2つの結果にたどり着いた。
これによりもう一つの追加のセキュリティモジュールであるTOMOYO Linuxが2009年6月、メインラインカーネル バージョン2.6.30に統合されるまでLSMは存続することが出来た。 注意すべきことに、LSMを利用して実装されたセキュリティモジュールはカーネル内に互いに共存できるが、同時実行できない。例えば、SELinuxとTOMOYO Linux（バージョン2）はカーネルコンフィグレーション(Kconfig)で両方をYesに選択、カーネル内に両者をリンクできるが、実行時にはどちらか一方のみしか有効化することができず、またその方法は起動時のカーネルパラメータにどのセキュリティモジュールを使用するか指定することとなる。（カーネルコンフィグレーションにて、自動的に有効化するセキュリティモジュールを選択することもできる。）Linuxカーネルバージョン2.6.24以前は、上述のとおり完全な強制アクセス制御を持つセキュリティモジュールをLKMとして実装可能だったが、このバージョン以降、特殊な回避方法を用いない限り、LKMとしてはセキュリティモジュールを実装できなくなった。（通常はセキュリティモジュールをカーネルに静的にリンクする必要がある。）そのような特殊な回避方法を用いたモジュールにTOMOYO Linuxの開発者である半田哲夫が作成したAKARIがある[7][8]。 批判一部のLinuxカーネル開発者はLSMを様々な理由で嫌っている。LSMは、とりわけモジュールが何もロードされない場合において、可能な限りオーバーヘッドを最小限に留めようとするが、そのコストはゼロではなく、この点に反感を持っているLinux開発者もいる。現時点ではLSMはアクセス制御機能提供のためのみに設計されているが、その他の利用方法でLSMを使用することを実際には妨げてはいない。そのため、他の使用目的により「乱用」される可能性、とりわけ、通常はカーネルへのアクセス可能な機能が限定されている、GPLでライセンスされていないプロプライエタリなモジュールがそれらにアクセスする目的でLSMを使いバイパス出来てしまう点を一部のLinuxカーネル開発者は嫌っている。「乱用」の例としては、本来のセキュリティフレームワークとしての役割ではなく特権的なケーパビリティを作成するために専ら利用する、"Realtime LSM"なるモジュールが以前あった[9][10]。Realtime LSMはレイテンシ低減に役立つため、一時期アンドリュー・モートンの管理するmmツリーにマージされ[11]、Linuxをデジタル・オーディオ・ワークステーションとして使用するユーザーの間では特に利用されていたが、LSMを使用するモジュールがLKMとして実装できなくなったカーネルバージョン2.6.24からは最早利用できない。 コンピュータセキュリティ技術者であっても同様にLSMを嫌っている場合がある。grsecurityの作者は歴史的な理由もあり、次のような理由でLSMを嫌悪している。LSMは必要とするすべてのシンボルをエクスポートするが、この中にはセキュリティモジュールと同様の処理でルートキットのような有害なモジュールの挿入を許すことにつながるものがある[12]。RSBACの作者もRSBACが必要とするものに対してLSMが不完全であるため嫌っている。とりわけRSBACの作者は次のような主張をしている。「LSMは追加的、制限的アクセス制御のみが実装されているが、RSBACシステムは多くの追加機能を提供する。例えば、シンボリックリンクリダイレクション、secure_delete、Linuxの部分的任意アクセス制御無効化機能がそれに当たる。これらは全てRSBACプロジェクト独自のパッチによりカーネルの機能追加を行わなければならない[13]。」Dazukoの作者は次のような主張をしていた。メインラインカーネルツリーに未だ取り込まれず、ツリー外部におけるメンテナンス作業をする限り、LSMのAPIを実装目標とすることは、常にそのターゲットが変化することに等しい。なぜならLSMに限らずカーネルのAPIはリリースの度に変化するからである[14]。とはいえ、これはリーナスが管理するメインストリームカーネルツリーに含まれない全てのカーネルモジュール、デバイスドライバにも当てはまる話である。ちなみにDazukoはファイルシステムスキャンの名目でファイルシステムへのアクセス制御を行うデバイスドライバである。このドライバを使用すると、ファイルシステムのロギングやモニタリングを行うことが可能となる。バージョン2まではデバイスドライバであったが、ファイルシステムへのアクセスのみを行うことから、バージョン3以降からは完全なファイルシステムとなっている[15]。バージョン2まではLSMを使用するかまたはシステムコールの独自フックを有効化するかコンパイル時に決定できたが、バージョン3からはLSMを直接利用していない。バージョン3はLSM挿入済みのLinux VFSを使用していることから間接的にはLSMを使用していることになるが、それは「LSMの上に実装するセキュリティモジュール」という意味を成さず、Linuxでサポートされているその他のファイルシステムと全く同等であるという意味しかない。 脚注注釈出典
関連項目
外部リンク
|
Portal di Ensiklopedia Dunia
