セキュアな Linux: 第 1 回 SELinux ― その開発の歴史、アーキテクチャー、そして動作原理

Linux に強制アクセス制御 (MAC: Mandatory Access Control) 機能を提供する強力なモジュールである Security-Enhanced Linux に関して、その開発の歴史における基本的なマイルストーン、アーキテクチャー、動作原理を学んでください。この記事は世界の developerWorks 読者に提供するための記事として、developerWorks ロシアに投稿された記事から特別に選ばれて翻訳されたものです。

Evgeny Ivashko, Specialist, Author

Evgeny Ivashko は、Institute of the Russian Academy of Sciences、Institute of Applied Mathematical Research、Karelian Research Center of the Russian Academy of Sciences の会員です。



2012年 6月 28日

SELinux の歴史

Linux に強制アクセス制御 (MAC: Mandatory Access Control) 機能を提供する SELinux (Security-Enhanced Linux) システムの開発を伴うプロジェクトは、米国国家安全保障局 (NSA: National Security Agency) 内部で開始されました。SELinuxの開発には数々の研究所の他、SCC (Secure Computing Corporation) と MITRE の 2 社も直接関与しています。SELinux は 2000年 12月に一般公開されたソフトウェア製品 (GPL ライセンスの下、ソース・コードを配布) としてリリースされました。NSA はこれを記念して、特別なプレス・リリースを行いました (「参考文献」を参照)。リリースを迎えるまでの 10 年もの間、SELinux の基本的なアーキテクチャーは、半ば研究目的、半ば軍事目的のいくつかのプロジェクトのなかで開発、分析、テストされてきました (「華やかなプロジェクトの数々: DTMach、DTOS、Fluke、Flusk、Flask」を参照)。


華やかなプロジェクトの数々: DTMach、DTOS、Fluke、Flusk、Flask

1992年から 1993年までの間、NSA と SCC の研究者たちは、DTMach (Distributed Trusted Mach) の作成に取り組んでいました。DTMach は、TMach プロジェクトと LOCK プロジェクトによる成果を結集したオペレーティング・システムであり、ここに、包括的な Type Enforcement、柔軟なアクセス制御メカニズム、そして Mach マイクロカーネルが統合されました。DTMach プロジェクトはその後、DTOS (Distributed Trusted Operating System) プロジェクトの一部として開発されるようになりました。DTOS プロジェクトが完了した後、続いて NSA、SCC、そしてユタ大学 (University of Utah) が共同で取り組んだのが、DTOS セキュリティー・システムのアーキテクチャーを Fluke 研究用オペレーティング・システムに統合するプロジェクトです。この新しいプロジェクトは、Flux と名付けられました。それと並行して、DTOS セキュリティー・システムのオリジナルのアーキテクチャーが強化され、動的なセキュリティー・ポリシーを十分サポートするようになりました。この強化されたアーキテクチャーは、Flask と名付けられました。そして次の段階で、NSA がこのセキュリティー・システム・アーキテクチャーを Linux OS 用に実装し、これにより、このアーキテクチャーが Security-Enhanced Linux という名前で一般公開されるに至りました (「参考文献」を参照)。

この新しい強制アクセス制御システムは、オペレーティング・システムのオブジェクトとサブジェクトのセキュリティー・ラベルのチェック・プロセスをベースに、数々の最新アクセス制御技術を導入しています。その 1 つは、Type Enforcement です。Type Enforcement は当初、LOCK と呼ばれる特別に設計された信頼性の高い「A1」レベル・システム (「参考文献」を参照) でテストされていましたが (「LOCK」を参照)、その後、研究用オペレーティング・システム Flask のセキュリティー・サブシステムで開発されるようになりました。Type Enforcement は、特に SELinux ロール・ベースのアクセス制御とマルチレベル・セキュリティーまたはマルチカテゴリー・セキュリティーを使用した実装をサポートするために利用されています。


Type Enforcement

Type Enforcement とは、現行のセキュリティー・コンテキストまたはドメインに応じて、オブジェクト (ファイル、I/O ポート、その他) へのアクセス権限をサブジェクト (ユーザー、ソフトウェア・プロセスおよびフロー) に付与するアクセス制御技術です。

SELinux では、セキュリティー・コンテキストを拡張ファイルシステム属性に保管し、LSM (Linux Security Module) を使用して管理します。Type Enforcement は、強制アクセス制御を実装するために必要であり、ロール・ベース・アクセス制御 (RBAC) を補完するものです。そして、マルチレベル・セキュリティー (MLS) およびマルチカテゴリー・セキュリティー (MCS) への最初のステップの 1 つでもあります。


LOCK

SCC での LOCK (Logical Co-processing Kernel) プロジェクトの取り組みで目的とされたのは、マルチレベル・セキュリティーを提供する信頼性の高いコンピューター・システムを開発することです。これは、セキュリティー評価基準である TCSEC (Trusted Computing System Evaluation Criteria、「オレンジ・ブック」としても知られています) の基準で「A1」要件を満たすシステムにしなければならないことを意味していました。

LOCK プロジェクトは成功を収め、数十のシステムが軍事司令センターに導入される結果となりました。LOCK 技術のアーキテクチャーの主要な特徴はType Enforcement です。この技術によって、アクセス制御メカニズムの実装が確実に効果を発揮することとなりました。

セキュリティーとアクセス制御 (Type Enforcement を含む) に関連する基本的な LOCK 技術は、現在以下のシステムで開発されています。

  • Sidewinder Internet Firewall 製品ライン
  • SELinux

LOCK プロジェクトの詳細については、「参考文献」を参照してください。

SELinux はリリース時に、2.2 および 2.4 カーネルの更新として配布されましたが、SELinux を正式なカーネルに組み込むかどうかに関する疑問が浮上してきました。そこで Linus Torvalds 氏が要請したのが、以降の保守や機能強化が容易になるように、SELinux を修正して、Linux セキュリティー・サブシステムをモジュールとして実装可能にすることです。開発者たちはこの要請に応じて、Linux Security Modules サブシステムを作成し、カーネル機能にセキュリティー・サブシステム用のインターフェースを提供しました。このソリューションによって、Linux ディストリビューションのユーザーならびに開発者は、AppArmor、TOMOYO Linux、SMACK、SELinux のなかから強制アクセス制御システムを選択できるようになっています。


Linux Security Modules

LSM (Linux Security Modules) は、モジュールとして実装されたカーネルの各種セキュリティー・モジュールに統合するように設計された Linux カーネル・サブシステムです。2001年の Linux カーネル・サミットで、NSA の代表は、強制アクセス制御システム SELinux を Linux カーネル・バージョン 2.5 に組み込むことを提案しましたが、Linus Torvalds 氏はこの提案を却下しました。Linux のセキュリティーを強化するために開発中のセキュリティー・システムは SELinux だけではないというのが、却下の理由です。それに加え、SELinux が最高のソリューションであると開発者全員が同意しているわけでもありませんでした。SELinux を直接カーネルに統合する代わりに、セキュリティー・サブシステムをモジュールとして使用可能にする方法として考案されたのが、LSM システムです。それは、比較的簡単に新しいモジュールを接続できることを意味していました。

LSM サブシステムは開発におよそ 3 年間の歳月が費やされた末、Linux カーネル・バージョン 2.6 以降から LSM が組み込まれるようになっています。現在公式にサポートされているセキュリティー・モジュールには、SELinux、Apparmor、Smack、および TOMOYO Linux があります。

LSM アーキテクチャーの詳細は、2002年の USENIX セキュリティー・カンファレンスで発表された記事、「Linux Security Modules: General Security Support for the Linux Kernel」(「参考文献」を参照) で説明されています。

SELinux が関係する強制アクセス制御システムは、ラベル制御をベースとしています。これはつまり、SELinux で保護されるオペレーティング・システム内のすべてのオブジェクトまたはサブジェクトには、「セキュリティー・コンテキスト」と呼ばれる、それぞれに固有の特殊なラベルが必要であることを意味します。これらのラベルは当初、ext2 ファイルシステムのノード内の未使用フィールドに数値として保管されていました。それぞれの数値ラベルが、SELinux 内で、人間が読んで理解できるテキスト・ベースのセキュリティー・コンテキスト・ラベルにマッピングされるという仕組みです。この手法はスケーラブルではない上に、特定の ext2 ファイルシステムの機能をベースにしていたため、この点が、ソリューション全体での明らかな欠点であると考えられていました。

開発の次のフェーズで、SELinux は Linux カーネル・バージョン 2.4 にロード可能なモジュールとして実装されました。モジュールは、別個のファイルに保管されたラベルを使用して動作するため、この SELinux 実装には使用するファイルシステムに関する制限がまったくありませんでした。その一方、アーキテクチャー上の問題を取り除いたことにより、別の問題が現れる結果となりました。それは、セキュリティー・コンテキスト・ラベルを保管するファイルへのアクセスが頻繁に発生し、それによって生産性が急激に低下したことです。

この問題は最終的に、Linux バージョン 2.6 のリリースで解決されました。Linux バージョン 2.6は、LSM と、ext3 ファイルシステム内の拡張属性を完全にサポートします。システムのオブジェクトおよびサブジェクトのセキュリティー・コンテキスト・ラベルを保管できるように、SELinux は拡張属性を使用する方法へと切り替えましたが、残念なことに、この新たな方法は、再びファイルシステムの使用に関する制限を設ける結果となりました。SELinux は、拡張属性をサポートするファイルシステムでしか使用できなくなったためです。けれども、この問題は次第に収まっていき、今では一般的に使用されているほぼすべてのファイルシステムが拡張属性を完全にサポートするようになっています。つまり、SELinux で使用できるということです。

その後ほどなくして SELinux は Linux カーネルに統合され、2003年 8月 8日にリリースされたカーネル 2.6.0-test3 のサブシステムとして、初めてテスト用の配布が開始されました。リリースの一環として、カーネル 2.2 および 2.4 向けに、強制アクセス制御システム用のカーネル・パッチがリリースされ、それと同時にカーネル 2.4 に LSM のサポートが導入されたことにより、LSM 対応 SELinux が誕生する結果となりました。

SELinux は瞬く間に、保護された Linux システムならびに、Red Hat Enterprise Linux の最もよく使われている企業用ディストリビューション (Red Hat Enterprise Linux 4 以降) の 1 つでデファクト・スタンダードとなりました。その後、SELinux は広く使われている Debian および Fedora OS で採用されるようになり、人気が高まっていた Ubuntu (LTS バージョン 8.04 Hardy Heron 以降) でもサポートされるようになりました。それからかなり経った後、Novell (当時、開発中の AppArmor を Linux カーネルに組み込むことを計画していました) は、その OpenSUSE および SUSE Linux Enterprise ディストリビューションでの SELinux のサポートを開始します。

最終的には、よく使用されているすべてのディストリビューションの開発者たちが、SELinux をサポートするようになりました。現行の Linux カーネル・バージョン 2.6 では、SELinux が LSM を使用して動作しています。さらに、多くの SELinux 要素が、実際のカーネルに組み込まれるようになっています。

この強制アクセス制御システムの開発が辿ってきた長い道のりを監督してきたのは、NSA です。さらに、Linux カーネルへの SELinux の統合に関する基本的な取り組みは、Red Hat によっても支援されました。NSA の Web サイトに、SELinux の開発に大きく貢献した開発者たちの詳細なリストが掲載されています (「参考文献」を参照)。


SELinux のアーキテクチャー

前述のとおり、SELinux システムは、研究用オペレーティング・システム Flask のセキュリティー・サブシステムのアーキテクチャーを引き継いでいます。Flask の主な特徴は、「最小権限」の概念を使用して、要求されたアクションを実行するために必要なアクセス権限だけをユーザーまたはアプリケーションに付与することです。この概念は、Type Enforcement (「Type Enforcement」を参照) を使用して実装されることから、SELinux での強制アクセス制御は、ドメイン・タイプ・モデルの一部として動作することができます。ドメイン・タイプ・モデルでは、各プロセス・サブジェクトは定義されたセキュリティー・コンテキスト (つまり、ドメイン) で開始されます (各プロセス・サブジェクトが一定のアクセス・レベルを持つということです)。その一方、オペレーティング・システムのすべてのリソース・オブジェクト (ファイル、ディレクトリー、ソケットなど) には特定のタイプ (つまり、セキュリティー・レベル) が関連付けられます。

Type Enforcement のおかげで、SELinux には、UNIX 系のシステムで使用されている基本的な任意アクセス制御 (DAC: Discretionary Access Control) モデルが提供するオプションよりも遥かに多くのアクセス制御オプションがあります。例えば、SELinux を使用することで、ネットワーク・サーバーにアクセスを許可するネットワーク・ポート番号を厳格に制限することができます。また、SELinux を使用して、個々のファイルの作成とそのファイルへのデータ保存は許可する一方、削除は禁止するといったことなども可能です。このように細かい粒度でオペレーティング・システムのオブジェクトを制御できるということは、特定のリソースに明確に割り当てられたアクセス権限を使用して、システムおよびユーザー・プロセスを制限するのに役立ちます。たとえ、SELinux によって制御されているサービスでセキュリティーが侵害されたとしても、侵入者は一連のルールによって制限されたサンドボックスより先に進むことはできません。それは、侵入者がスーパーユーザー権限を持っているとしても同じことです。

特定のドメインに対して、特定のタイプへのアクセスを許可するパーミッションを定義するルールのリストも、セキュリティー・ポリシーの 1 つです。セキュリティー・ポリシーは、システムがセットアップされた時点から適用され、システムの起動中に、セキュリティー・ポリシーを構成する一連のテキスト・ファイルが Linux カーネルのメモリーにロードされます。

これらのルールは、人間が読んで理解できる形式になっていて、一般ユーザーでも理解することができます。例えば、以下に示すルールでは、HTTP サーバー・ドメインに対して、ネットワーク構成を含む一部のファイルの読み取り権限を付与しています。

allow httpd_t net_conf_t:file { read getattr lock ioctl };

SELinux は、Flask セキュリティー・サブシステムから「ドメイン・タイプ」モデルを継承しているだけでなく、オペレーティング・システムのオブジェクトとサブジェクトの両方のセキュリティー・コンテキストを定義するラベルを扱うための構造と原理も継承しています。全体的な保護を確実にするためには、セキュリティー・コンテキストをシステム内の各オブジェクトおよび各サブジェクトに対して定義する必要があります。ラベルは、以下の形式になっています。

allow httpd_t net_conf_t:file { read getattr lock ioctl };

分散セキュリティー・コンテキストのラベルを例にとると、その形式は system_u:object_r:httpd_exec_t となります。SELinux では、ユーザー system_u が一般に、システムのデーモンにデフォルトで付けられる名前です。ロール object_r は、ファイルやデバイスといったシステムの一般的オブジェクトに割り当てられます。httpd_exec_t タイプは、/usr/sbin/httpd に置かれた実行対象の httpd ファイルに適用されます。userroletype の各要素については、次回の記事でさらに詳しく説明する予定です。

図 1. SELinux を使用した強制アクセス制御システムの概要
データ・アクセス制御における SELinux の役割を示す図

SELinux は、以下の 5 つの基本コンポーネントからなります。

  • ファイルシステムで動作するための補助モジュール
  • LSM のイベント・フックを操作するモジュール
  • アクセス制御を体系化する基本メカニズム
  • Policy Enforcement Server (システム・セキュリティー・ポリシー・データベース)
  • Access Vector Cache (AVC、生産性を向上させるための補助メカニズム)

SELinux は以下のように動作します。

  1. オペレーティング・システムのサブジェクト (つまり、プロセス) が、特定のオブジェクト (ファイル、プロセス、ソケットなど) でアクションを実行しようとします。すると、Linux の標準的なセキュリティー・システムである任意アクセス制御 (DAC) システムの中で、このアクションの実行が許可されます。これにより、オブジェクトに対する一連の要求が開始されます。
  2. オブジェクトでアクションを実行するための要求はすべて、LSM によってインターセプトされ、サブジェクトおよびオブジェクトのセキュリティー・コンテキストと一緒に SELinux Abstraction & Hook Logic サブシステムに転送されます。このサブシステムは、LSM を操作する役割を担っています。
  3. SELinux Abstraction & Hook Logic サブシステムから受け取った情報は、基本コンポーネントである Policy Enforcement Server モジュールに転送されます。このモジュールが、当該サブジェクトに対してオブジェクトへのアクセスを許可するかどうかの決定に直接の責任を持ちます。
  4. アクションを許可するか、禁止するかについての決定を受け取るために、Policy Enforcement Server は特殊な AVC (Access Vector Cache) サブシステムに連絡します。ほとんどの場合、使用されるルールは AVC サブシステムにキャッシュされています。
  5. 該当するポリシーに応じた決定が AVC にキャッシュされていない場合、必要なセキュリティー・ポリシーに対する要求が再びセキュリティー・ポリシー・データベースに転送されます。
  6. セキュリティー・ポリシーが見つかった場合は、そのセキュリティー・ポリシーが、決定を受け取るポリシー・サーバーに転送されます。
  7. 要求されているアクションが、見つかったポリシーと適合する場合には、そのアクションの実行が許可されます。適合しない場合には、そのアクションの実行が禁止されて、決定要因となったすべての情報が SELinux ログ・ファイルに書き込まれます。

特定のアクションを許可または禁止するかどうかを決定するだけでなく、Policy Enforcement Server モジュールは、セキュリティー・ラベルの管理 (割当、削除) などといった補助タスクも行います。

優れたシステムの例に漏れず、SELinux は動作が単純であるため、動作の信頼性が高く、リソースの需要が低く、強制アクセス制御システム全体の生産性がかなりのレベルになることは間違いありません。


まとめ

連載「セキュアな Linux」の第 1 回となるこの記事では、GNU/Linux オペレーティング・システムで使用されているなかで最も知名度が高く、最も強力な強制アクセス制御システムである SELinux を取り上げました。

SELinux はその評判に違わぬ、信頼性の高いセキュリティー保護システムです。SELinux の信頼性に大きく貢献しているのは、SELinux を作成し、開発したのが NSA であるという事実ですが、NSA 当局の貢献とは別に、SELinux は IT システム・セキュリティーの分野における長年の科学的開発にも支えられています。これらの開発には深い理論的基礎があるとともに、専門的な軍事システムで実際に大きな効果を発揮することを証明しています。

その一方、SELinux は企業ネットワークや家庭の PC で使用するほどには単純ではありません。SELinux は、ラベル・ベースの強制アクセス制御システムに関係するためです。具体的に言うと、オペレーティング・システムの各オブジェクトと各サブジェクトには、ラベル、つまりセキュリティー・コンテキストを割り当てなければなりません。さらに、システム全体に対応するのに十分な SELinux セキュリティー・ポリシーには、平均で 100,000 を超えるルールが含まれます!したがって、現在の形でセキュリティー・ポリシーを作成し、改良し、保守するとなると、あまりにも多くの時間と作業が必要になります。このようなセキュリティー・ポリシーを既存のコンピューター・システムや、計画しているコンピューター・システム向けに一から作成することが当を得ているケースは、ごくわずかしかありません。それは例えば、保管および処理するデータの性質から、サーバーに極めて高い信頼性と保護能力が要求される場合などです。システムの批評家たちは、IT セキュリティーの観点から見て SELinux がこれほどまでに難攻不落である理由は、その複雑さに過ぎないと言っています。例えば、侵入者がシステムの防御を迂回できたとしたら、管理者が SELinux のセットアップを誤ったという言い訳がなされることでしょう。

ある特定のプログラムに対するアクセス・ルールを考案する際に、管理者が SELinux の制約を考慮していないアクションを思い付くこともあります。例えば、Linux でのアプリケーションには、部分的にスーパーユーザー権限を一般ユーザーの権限に切り替えるものや、その逆の切り替えを行うものがあります。つまり、これらのアプリケーションは最小権限の原則を適用すべく、スーパーユーザーの権限を使用するのは、どうしても必要な場合に限っているわけです。けれども、このような振る舞いを SELinux セキュリティー・モデルの一部として記述するのは簡単なことではありません。

そうは言っても、進歩は続いており、これらの問題のすべては常に開発者たちの監視下にあります。サーバーや家庭の PC での一般的な状況で使用できる完全なルール・セットもいくつか作成されました。これらのルール・セットを適用するには、システム管理者が既製のセキュリティー・ポリシーのいずれかを選択し、コンピューターをリブートして SELinux を有効にするだけです。

SELinux 自体も、セキュリティー・ポリシーを作成および開発するという形、そして開発者たちとの対話で既存のプログラムを修正するという形で、常に改善が続けられています。

連載「セキュアな Linux」の今後の記事では、SELinux を実際に使用するために、ルールを作成および改善する方法、SELinux の振る舞いを制御する方法、そして発生し得る問題を解決する方法について詳しく説明します。

参考文献

学ぶために

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source
ArticleID=822573
ArticleTitle=セキュアな Linux: 第 1 回 SELinux ― その開発の歴史、アーキテクチャー、そして動作原理
publish-date=06282012