セキュリティ強化Linux

カーネル

Arch Linuxの SELinux 管理者 GUI
原作者	NSAとレッドハット
開発者	レッドハット
初回リリース	2000年12月22日; 24年前[1] ( 2000-12-22 )
安定版リリース	3.6 / 2023年12月13日; 12か月前[2] ( 2023-12-13 )
リポジトリ	github.com/SELinuxProject/selinux
書かれた	Ｃ
オペレーティング·システム	リナックス
タイプ	セキュリティ、Linux セキュリティ モジュール(LSM)
ライセンス	GNU GPL
Webサイト	selinuxproject.org、https://www.nsa.gov/what-we-do/research/selinux/

Security-Enhanced Linux ( SELinux )は、強制アクセス制御(MAC) を含むアクセス制御セキュリティ ポリシーをサポートするためのメカニズムを提供するLinux カーネル セキュリティ モジュールです。

SELinuxは、さまざまなLinuxディストリビューションに追加されたカーネル修正とユーザー空間ツールのセットです。そのアーキテクチャは、セキュリティ決定の実施をセキュリティポリシーから分離し、セキュリティポリシーの実施に関係するソフトウェアの量を合理化することを目指しています。^{[3] [4]} SELinuxの基礎となる主要な概念は、米国国家安全保障局（NSA）によるいくつかの以前のプロジェクトにまで遡ることができます。

NSAセキュリティ強化LinuxチームはNSA SELinuxを次のように説明している^[5]

Linux カーネルのパッチとユーティリティのセットで、カーネルの主要サブシステムに強力で柔軟な強制アクセス制御 (MAC) アーキテクチャを提供します。機密性と整合性の要件に基づいて情報の分離を強制する強化メカニズムを提供し、改ざんやアプリケーション セキュリティ メカニズムのバイパスの脅威に対処し、悪意のあるアプリケーションや欠陥のあるアプリケーションによって引き起こされる可能性のある損害を制限できます。一般的な汎用セキュリティ目標を満たすように設計されたサンプル セキュリティ ポリシー構成ファイルのセットが含まれています。

SELinux を統合した Linux カーネルは、ユーザー プログラムとシステム サービス、およびファイルとネットワーク リソースへのアクセスを制限する強制アクセス制御ポリシーを適用します。権限を動作に必要な最小限に制限することで、これらのプログラムとデーモンが障害または侵害を受けた場合に (たとえば、バッファ オーバーフローや誤った構成によって) 害を及ぼす可能性が低減または排除されます。この制限メカニズムは、従来の Linux (任意) アクセス制御メカニズムとは独立して動作します。「ルート」スーパーユーザーの概念はなく、 setuid / setgidバイナリへの依存など、従来の Linux セキュリティ メカニズムのよく知られた欠点を共有しません。

「変更されていない」Linux システム (SELinux のないシステム) のセキュリティは、カーネル、すべての特権アプリケーション、およびそれぞれの構成の正確さに依存します。これらの領域のいずれかに欠陥があると、システム全体が危険にさらされる可能性があります。対照的に、「変更された」システム (SELinux カーネルに基づく) のセキュリティは、主にカーネルとそのセキュリティ ポリシー構成の正確さに依存します。アプリケーションの正確さや構成に問題があると、個々のユーザー プログラムやシステム デーモンが限定的に危険にさらされる可能性がありますが、他のユーザー プログラムやシステム デーモンのセキュリティやシステム全体のセキュリティに必ずしも脅威となるわけではありません。

純粋主義的な観点から見ると、SELinux は、強制アクセス制御、強制整合性制御、ロールベース アクセス制御(RBAC)、およびタイプ強制アーキテクチャから抽出された概念と機能のハイブリッドを提供します。サードパーティ ツールを使用すると、さまざまなセキュリティ ポリシーを構築できます。

UNIX (より正確には POSIX) コンピューティング環境内で強制アクセス制御と任意アクセス制御 (MAC と DAC) を提供するアプローチの標準化に向けた最も初期の作業は、国家安全保障局の Trusted UNIX (TRUSIX) ワーキング グループによるものです。このワーキング グループは 1987 年から 1991 年にかけて会合を開き、1 冊のRainbow Book (#020A)を出版し、正式なモデルと関連する評価証拠のプロトタイプ (#020B) を作成しましたが、最終的には未公開となりました。

SELinux は、Linux コミュニティに強制アクセス制御の価値を示し、そのような制御を Linux に追加する方法を示すために設計されました。当初、SELinux を構成するパッチは Linux カーネル ソースに明示的に適用する必要がありましたが、SELinux はLinux カーネル 2.6 シリーズで Linux カーネル メインラインに統合されました。

SELinuxの元々の主要な開発者であるNSAは、2000年12月22日にGNU GPLの下でオープンソース開発コミュニティに最初のバージョンをリリースしました。 ^[6]このソフトウェアは、2003年8月8日にリリースされたメインラインLinuxカーネル2.6.0-test3に統合されました。その他の重要な貢献者には、Red Hat、Network Associates、Secure Computing Corporation、Tresys Technology、Trusted Computer Solutionsが含まれます。FLASK /TE実装の実験的な移植版は、TrustedBSDプロジェクトを通じてFreeBSDおよびDarwinオペレーティングシステム用に提供されています。

セキュリティ強化 Linux はFlux Advanced Security Kernel (FLASK) を実装しています。このカーネルには Fluke オペレーティング システムでプロトタイプ化されたアーキテクチャ コンポーネントが含まれています。これらは、タイプ強制、ロール ベース アクセス制御、およびマルチレベル セキュリティの概念に基づくものを含む、多くの種類の強制アクセス制御ポリシーを実施するための一般的なサポートを提供します。FLASK は、Mach から派生した分散型信頼オペレーティング システムである DTOS と、DTOS の設計と実装に影響を与えたTrusted Information Systemsの研究プロジェクトである Trusted Mach に基づいています。^{[引用が必要]}

SELinux のオリジナルおよび外部貢献者の包括的なリストは、2009 年にメンテナンスが終了するまで NSA の Web サイトでホストされていました。次のリストは、インターネット アーカイブ ウェイバック マシンに保存されているオリジナルのリストを再現したものです。貢献の範囲はページに記載されており、簡潔にするために省略されていますが、アーカイブされたコピーからアクセスできます。^[7]

SELinux のユーザーとロールは、実際のシステム ユーザーとロールに関連している必要はありません。現在のすべてのユーザーまたはプロセスに対して、SELinux はユーザー名、ロール、ドメイン (またはタイプ) で構成される 3 つの文字列コンテキストを割り当てます。このシステムは通常必要とされるよりも柔軟です。原則として、実際のユーザーのほとんどは同じ SELinux ユーザー名を共有し、すべてのアクセス制御は 3 番目のタグであるドメインによって管理されます。プロセスが特定のドメインに入ることが許可される状況は、ポリシーで設定する必要があります。このコマンドを使用すると、runcon明示的に指定されたコンテキスト (ユーザー、ロール、ドメイン) へのプロセスの開始が許可されますが、ポリシーによって承認されていない場合は、SELinux が遷移を拒否することがあります。

ファイル、ネットワーク ポート、その他のハードウェアにも SELinux コンテキストがあり、名前、ロール (めったに使用されない)、タイプで構成されます。ファイル システムの場合、ファイルとセキュリティ コンテキスト間のマッピングはラベル付けと呼ばれます。ラベル付けはポリシー ファイルで定義されますが、ポリシーを変更せずに手動で調整することもできます。ハードウェア タイプは、bin_t(フォルダー /bin 内のすべてのファイル) やpostgresql_port_t(PostgreSQL ポート、5432) など、非常に詳細です。リモート ファイル システムの SELinux コンテキストは、マウント時に明示的に指定できます。

SELinux は、、などのシェル コマンドにスイッチを追加し、ファイルまたはプロセスのセキュリティ コンテキストを確認できるようにします -Z。lsps

一般的なポリシー ルールは、明示的な権限で構成されます。たとえば、特定のターゲットで特定のアクション (読み取り、実行、またはネットワーク ポートの場合はバインドまたは接続) を実行するためにユーザーが所有する必要があるドメインなどです。役割やセキュリティ レベルを含む、より複雑なマッピングも可能です。

一般的なポリシーは、ドメイン遷移を定義するマッピング (ラベル付け) ファイル、ルール ファイル、およびインターフェイス ファイルで構成されます。これらの 3 つのファイルを SELinux ツールでコンパイルして、1 つのポリシー ファイルを作成する必要があります。作成されたポリシー ファイルは、カーネルにロードしてアクティブにすることができます。ポリシーのロードとアンロードには、再起動は必要ありません。ポリシー ファイルは、手動で作成するか、よりユーザー フレンドリな SELinux 管理ツールから生成することができます。通常、ポリシーは最初に permissive モードでテストされ、違反はログに記録されますが、許可されます。このaudit2allowツールは、後で追加のルールを作成するために使用して、制限されているアプリケーションの正当なアクティビティをすべて許可するようにポリシーを拡張することができます。

SELinux の機能には以下が含まれます。

• 政策と執行を明確に分離
• 明確に定義されたポリシーインターフェース
• ポリシーを照会し、アクセス制御を実施するアプリケーションのサポート（たとえば、正しいコンテキストでジョブを実行するcrond など）
• 特定のポリシーとポリシー言語の独立性
• 特定のセキュリティラベル形式と内容の独立性
• カーネルオブジェクトとサービスの個別のラベルとコントロール
• 政策変更への支援
• システムの完全性（ドメイン型）とデータの機密性（マルチレベルセキュリティ）を保護するための個別の対策
• 柔軟なポリシー
• プロセスの初期化と継承、プログラムの実行を制御する
• ファイルシステム、ディレクトリ、ファイル、および開いているファイル記述子の制御
• ソケット、メッセージ、ネットワークインターフェースの制御
• 「機能」の使用に対する制御
• アクセスベクターキャッシュ（AVC）を介してアクセス決定に関するキャッシュされた情報^[8]
• デフォルト拒否ポリシー（ポリシーで明示的に指定されていないものはすべて禁止される）^{[9] [10] [11]}

SELinuxはAndroidバージョン4.3以降に実装されています。 ^[12]

無料のコミュニティサポートLinuxディストリビューションの中で、Fedoraは最も早くSELinuxを採用したディストリビューションの1つであり、Fedora Core 2以降、デフォルトでSELinuxをサポートしています。他のディストリビューションでは、Debianのバージョン9 Stretchリリース以降^[13]、Ubuntuのバージョン8.04 Hardy Heron以降^[14]がSELinuxをサポートしています。openSUSEのバージョン11.1以降、SELinuxの「基本的な有効化」が含まれています。^[15] SUSE Linux Enterprise 11は、SELinuxを「技術プレビュー」として提供しています。^[16]

SELinuxは、 CoreOS Container LinuxやrktなどのLinuxコンテナをベースにしたシステムで人気があります。 ^[17]デプロイされたコンテナとホスト間の分離をさらに強化するための追加のセキュリティ制御として役立ちます。

SELinux は、2005 年からRed Hat Enterprise Linux (RHEL) バージョン 4 および将来のすべてのリリースで使用できます。この存在は、 CentOS、Scientific Linux、AlmaLinux、Rocky Linuxなどの派生システムの対応するバージョンにも反映されています。 RHEL4 でサポートされているポリシーは、最大限の使いやすさを目的としたターゲット ポリシーであり、それほど制限的ではありません。 RHEL の将来のバージョンでは、ターゲット ポリシーにさらに多くのターゲットが含まれるように計画されており、ポリシーの制限が厳しくなります。

SELinux は、非常に正確な仕様で、システムが各ユーザー、プロセス、デーモンに許可するアクティビティを潜在的に制御できます。これは、データ アクセスとアクティビティの権限が明確に定義されているデータベース エンジンや Web サーバーなどのデーモンを制限するために使用されます。これにより、制限されたデーモンが侵害されても、潜在的な被害が制限されます。

コマンドラインユーティリティには、^[18] chcon、^[19] restorecon、^[20] restorecond、^{[ 21]} runcon、 [22 ] 、[ ^23]、^[24]、^[25]、^[26]、^[27]、^[28]、^{[29] [30]}、 ^[31]、 [ ^32]、 [ ^33]などが ある。 secon fixfiles setfiles load_policy booleans getsebool setsebool togglesebool setenforcesemodulepostfix-nochrootcheck-selinux-installationsemodule_packagecheckmoduleselinux-config-enforcing selinuxenabledselinux-policy-upgrade

SELinux を強制モードにするには:

setenforce 1

SELinux ステータスを照会するには:

getenforce

SELinux は、インストールされたソフトウェアが実行できるアクションを制限するという問題に対する、いくつかの可能なアプローチの 1 つです。もう 1 つの一般的な代替手段はAppArmorと呼ばれ、 SUSE Linux Enterprise Server (SLES)、openSUSE、およびDebian ベースのプラットフォームで利用できます。AppArmor は、現在は廃止されたImmunix Linuxプラットフォームのコンポーネントとして開発されました。AppArmor と SELinux は根本的に異なるため、ソフトウェア制御の異なる代替手段となります。SELinux は、より表現力豊かなポリシー選択セットへのアクセスを提供するために特定の概念を再発明しますが、AppArmor は、 DACで使用されるのと同じ管理セマンティクスを強制アクセス制御レベルまで拡張することで、シンプルになるように設計されています。

いくつかの重要な違いがあります:

• 重要な違いの 1 つは、AppArmor がファイル システム オブジェクトを inode ではなくパス名で識別することです。つまり、たとえば、アクセスできないファイルは、ハード リンクが作成されると AppArmor でアクセス可能になる場合がありますが、SELinux は新しく作成されたハード リンクを介したアクセスを拒否します。
  • その結果、ファイルにタイプが割り当てられず、構成ファイルで参照されるだけなので、 AppArmor はタイプ強制システムではないと言えます。
• SELinuxとAppArmorは、管理方法やシステムへの統合方法も大きく異なります。^[34]
• AppArmor は MAC レベルの強制で従来の DAC 制御を再現しようとしているため、その操作セットもほとんどの SELinux 実装で利用可能な操作セットよりもかなり小さくなっています。たとえば、AppArmor の操作セットは、読み取り、書き込み、追加、実行、ロック、リンクで構成されています。^[35]ほとんどの SELinux 実装は、これより桁違いに多くの操作をサポートします。たとえば、SELinux は通常、同じ権限をサポートしますが、mknod、ネットワーク ソケットへのバインド、POSIX 機能の暗黙的な使用、カーネル モジュールのロードとアンロード、共有メモリにアクセスするさまざまな方法などの制御も含まれています。
• AppArmor には、POSIX 機能をカテゴリ的に制限するコントロールはありません。現在の機能の実装には操作の対象の概念が含まれないため (アクターと操作のみ)、アクターによって強制された制御領域 (つまり「サンドボックス」) の外部にあるファイルに対する特権操作を防ぐのは、通常、MAC レイヤーの役割です。AppArmor は、自身のポリシーが変更されるのを防ぎ、ファイル システムがマウント/アンマウントされるのを防ぐことができますが、ユーザーが承認された制御領域から外に出るのを防ぐことはできません。
  • たとえば、ヘルプデスクの従業員が、たとえ自分が所有していなくても、特定のファイルの所有権や権限を変更できると便利だと考えられる場合があります (たとえば、部門のファイル共有)。管理者は、ユーザーにボックスのルート アクセスを与えたくないので、ユーザーにCAP_FOWNERまたは を与えますCAP_DAC_OVERRIDE。SELinux では、管理者 (またはプラットフォーム ベンダー) は、制限のないユーザーに対してすべての機能を拒否するように SELinux を構成し、その後、ログイン後に従業員が移行できる制限付きドメインを作成できます。このドメインでは、適切な種類のファイルに対してのみ、それらの機能を行使できます。^{[引用が必要]}
• AppArmor には多層セキュリティの概念がないため、BLPやBiba の厳格な適用は利用できません。^{[引用が必要]}。
• AppArmor の設定は、通常のフラット ファイルのみを使用して行われます。SELinux (ほとんどの実装ではデフォルト) は、フラット ファイル (管理者と開発者がコンパイル前に人間が読めるポリシーを記述するために使用) と拡張属性の組み合わせを使用します。
• SELinux は、ポリシー設定の代替ソースとして「リモート ポリシー サーバー」の概念 (/etc/selinux/semanage.conf で設定可能) をサポートしています。管理者は、設定デプロイメント ツールをルートとして実行するか (ポリシーの更新を可能にするため)、各サーバーで手動で設定するかを決定する必要があるため、AppArmor の集中管理は通常、かなり複雑です。

プロセスの分離は仮想化などのメカニズムによっても実現できます。たとえば、 OLPCプロジェクトでは、最初の実装^[36] で、軽量のVserverで個々のアプリケーションをサンドボックス化しました。また、NSAはSecurity-Enhanced AndroidでSELinuxの概念の一部を採用しています。^[37]

ジェネラルダイナミクスは、 Red Hat Enterprise Linuxのマルチレベルセキュリティ（MLS）拡張機能であるPitBull Trusted Operating System ^[38]を構築し配布しました。

マルチカテゴリーセキュリティ（MCS）は、Red Hat Enterprise LinuxのSELinuxの拡張機能であり、ユーザーがファイルにカテゴリーを付けて、裁量的アクセス制御とタイプの強制によってアクセスをさらに制限できるようにします。カテゴリーは、マルチレベルセキュリティ（MLS）で使用される機密レベル内に追加のコンパートメントを提供します。 ^[39]

• AppArmor  – Linux カーネル セキュリティ モジュール
• Astra Linux  – ロシアの Linux ベースのコンピュータ オペレーティング システム
• Red Star OS  – 北朝鮮の Linux ベースのオペレーティング システム
• ルールセットベースのアクセス制御 (RSBAC)  – Linux カーネルのアクセス制御フレームワーク
• 簡素化された強制アクセス制御カーネル – Linux カーネル セキュリティ モジュールリダイレクト先の簡単な説明を表示するページ
• Solaris Trusted Extensions  – Solaris オペレーティング システムのセキュリティ拡張機能
• Tomoyo  – Linux カーネル セキュリティ モジュールリダイレクト先の簡単な説明を表示するページ
• TrustedBSD  – 無料でオープンソースの Unix ライクなオペレーティング システムリダイレクト先の簡単な説明を表示するページ
• Unix セキュリティ
• Qubes OS  – セキュリティ重視の Linux ベースのオペレーティング システム

• 公式サイト
• インターネット アーカイブの国家安全保障局におけるセキュリティ強化 Linux
• GitHub上の SELinux
• Walsh, Daniel J (2013 年 11 月 13 日)。「SELinux ポリシー強制のビジュアル ガイド」。Opensource.com。