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ベースのセキュリティモジュールである。

カーネルソースコードディレクトリのトップにあるsecurity/というディレクトリの下にカーネル内処理に関するサブルーチン群が、include/linux/security.hヘッダファイルに主要な関数・構造体のプロトタイプ宣言や有益なマクロ、インライン関数がある。

名称より誤解を受けることが多いが、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つの結果にたどり着いた。

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

これによりもう一つの追加のセキュリティモジュールである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でサポートされているその他のファイルシステムと全く同等であるという意味しかない。

脚注

[編集]
[脚注の使い方]

注釈

[編集]
  1. ^ AppArmorの開発元だったが、2005年にノベルにより買収された。しかし2007年にはAppArmorの開発者はノベルに解雇させられている。その後Ubuntu開発元のカノニカルが彼らを雇用している。

出典

[編集]
  1. ^ “Linux Security Modules: General Security Support for the Linux Kernel” (2002年). 2007年2月3日閲覧。
  2. ^ CQual
  3. ^ “Using CQUAL for Static Analysis of Authorization Hook Placement” (2002年). 2007年2月3日閲覧。
  4. ^ Crispin Cowan (2001年4月11日). “Linux Security Module Interface”. linux-kernel mailing list. 2007年2月3日閲覧。
  5. ^ James Morris (2006年4月17日). “Time to remove LSM”. linux-kernel mailing list. 2011年1月25日閲覧。
  6. ^ “Linux Security Module は不要なのか？”. スラッシュドット・ジャパン (2006年4月19日). 2011年1月25日閲覧。
  7. ^ “AKARI: アクセスの保存および制限を行うためのツール”. akari.sourceforge.jp (2011年1月16日). 2011年1月25日閲覧。
  8. ^ 小崎資広(KOSAKI Motohiro) (2010年10月14日). “AKARI がどうやって、LSMフックの乗っ取っているのか調べてみた”. mkosaki.blog46.fc2.com. 2011年1月25日閲覧。
  9. ^ “Realtime Linux Security Module”. SourceForge.net (2009年7月17日). 2011年1月27日閲覧。
  10. ^ “Linux: Realtime Linux Security Module, 2.6 Latency”. KernelTrap（英語版） (2004年12月29日). 2013年5月3日時点のオリジナルよりアーカイブ。2011年1月27日閲覧。
  11. ^ Jack O'Quin (2005年2月11日). “realtime-lsm in Andrew Morton's latest kernel patchset”. linux-audio-dev mailing list. 2011年1月27日閲覧。
  12. ^ “"grsecurity - Why doesn't grsecurity use LSM?" 等”. grsecurity. 2007年2月3日閲覧。
  13. ^ “RSBAC and LSM”. RSBAC. 2007年2月3日閲覧。
  14. ^ “2.10 What are the known issues with the LSM (Linux Security Modules) system?”. dazuko.org. 2007年10月2日閲覧。
  15. ^ “Dazuko - A Stackable Filesystem to Allow Online File Access Control”. dazuko.dnsalias.org. 2011年1月25日閲覧。

関連項目

[編集]
ポータル FLOSS
ポータル FLOSS

外部リンク

[編集]
スタブアイコン

この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

スタブアイコン

この項目は、FLOSSに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（Portal:FLOSS）。

「https://ja.wikipedia.org/w/index.php?title=Linux_Security_Modules&oldid=97138024」から取得