「Linux Security Modules」の版間の差分

名称より誤解を受けることが多いが、[[2011年]]現在におけるLSMは[[ローダブル・カーネル・モジュール]] (LKM) ではなく、カーネル内に[[静的リンク|静的にリンク]]される。またLSMの上に実装される各種セキュリティモジュールは以前はLKMとして実装可能であったが、現在では原則不可能である(（後述)）。

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

従来からLinux環境で利用されてきたセキュリティモジュール{{仮リンク|Pluggable authentication module|en|Pluggable authentication module}}（PAM (PAM, {{仮リンク|Linux PAM|en|Linux PAM}}）) はユーザー[[認証]]や[[ファイルパーミッション|パーミッション]]制御のみに特化しているが、LSMはそれよりもカバーする範囲は広い。

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

AppArmorの開発元だったが、[[2005年]]に[[ノベル (企業)|ノベル]]により買収された。しかし[[2007年]]にはAppArmorの開発者はノベルに[[レイオフ|解雇]]させられている。その後[[Ubuntu]]開発元の[[Canonicalカノニカル]]が彼らを雇用している。

}}</ref>。しかしながら、メインストリームカーネルツリー外でメンテナンスされ、未だ含まれないその他のLSMモジュールが当時あった。（その時点では、AppArmor、{{仮リンク|Linux Intrusion Detection System|en|Linux Intrusion Detection System}}（LIDS） (LIDS)、 [[FireFlier]]、[[CIPSO]]、[[Multi ADM]]などが当てはまる。）LSMが存在しなければこれらのメインストリームカーネルツリーへの[[マージ]]はより困難、もしくは不可能となってしまう。またSELinux開発者の中には、AppArmorが（直接議論には上がっていないが、TOMOYO Linuxも当てはまる）ファイル[[環境変数|パス]]名ベースのアクセス制御であることに対し、ラベルベースのアクセス制御であるSELinuxの方が「ファイルなどという常にコロコロ変わるものをベースにする実装より厳密かつ優位に立つ」と主張する者もいた。この議論は2つの結果にたどり着いた。