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カーネルにおける標準的なセキュリティサポート）と言う形で発表された。同じカンファレンスにおいて、Using CQUAL for Static Analysis of Authorization Hook Placement（フック配置の認容の静的な解析のためのCQUALの使用）という、必要なすべてのフックが実際にカーネルに挿入されたことを検証するカーネルソースコードの静的な自動解析に関する研究論文も発表されている。

批判

一部のLinuxカーネル開発者はLSMを様々な理由で嫌っている。LSMは、とりわけモジュールが何もロードされない場合において、可能な限りオーバーヘッドを最小限に留めようとするが、そのコストはゼロではなく、この点に反感を持っているLinux開発者もいる。現時点ではLSMはアクセス制御機能提供のためのみに設計されているが、その他の利用方法でLSMを使用することを実際には妨げてはいない。そのため、他の使用目的により「乱用」される可能性、とりわけ、通常はカーネルへのアクセス可能な機能が限定されている、GPLでライセンスされていないプロプライエタリなモジュールがそれらにアクセスする目的でLSMを使いバイパス出来てしまう点を一部のLinuxカーネル開発者は嫌っている。「乱用」の例としては、本来のセキュリティフレームワークとしての役割ではなく特権的なケーパビリティを作成するために専ら利用する、"Realtime LSM"なるモジュールが以前あった。Realtime LSMはレイテンシ低減に役立つため、一時期アンドリュー・モートンの管理するmmツリーにマージされ、Linuxをデジタル・オーディオ・ワークステーションとして使用するユーザーの間では特に利用されていたが、LSMを使用するモジュールがLKMとして実装できなくなったカーネルバージョン2.6.24からは最早利用できない。
コンピュータセキュリティ技術者であっても同様にLSMを嫌っている場合がある。grsecurityの作者は歴史的な理由もあり、次のような理由でLSMを嫌悪している。LSMは必要とするすべてのシンボルをエクスポートするが、この中にはセキュリティモジュールと同様の処理でルートキットのような有害なモジュールの挿入を許すことにつながるものがある。RSBACの作者もRSBACが必要とするものに対してLSMが不完全であるため嫌っている。とりわけRSBACの作者は次のような主張をしている。「LSMは追加的、制限的アクセス制御のみが実装されているが、RSBACシステムは多くの追加機能を提供する。例えば、シンボリックリンクリダイレクション、secure_delete、Linuxの部分的任意アクセス制御無効化機能がそれに当たる。これらは全てRSBACプロジェクト独自のパッチによりカーネルの機能追加を行わなければならない。」Dazukoの作者は次のような主張をしていた。メインラインカーネルツリーに未だ取り込まれず、ツリー外部におけるメンテナンス作業をする限り、LSMのAPIを実装目標とすることは、常にそのターゲットが変化することに等しい。なぜならLSMに限らずカーネルのAPIはリリースの度に変化するからである。とはいえ、これはリーナスが管理するメインストリームカーネルツリーに含まれない全てのカーネルモジュール、デバイスドライバにも当てはまる話である。ちなみにDazukoはファイルシステムスキャンの名目でファイルシステムへのアクセス制御を行うデバイスドライバである。このドライバを使用すると、ファイルシステムのロギングやモニタリングを行うことが可能となる。バージョン2まではデバイスドライバであったが、ファイルシステムへのアクセスのみを行うことから、バージョン3以降からは完全なファイルシステムとなっている。バージョン2まではLSMを使用するかまたはシステムコールの独自フックを有効化するかコンパイル時に決定できたが、バージョン3からはLSMを直接利用していない。バージョン3はLSM挿入済みのLinux VFSを使用していることから間接的にはLSMを使用していることになるが、それは「LSMの上に実装するセキュリティモジュール」という意味を成さず、Linuxでサポートされているその他のファイルシステムと全く同等であるという意味しかない。