Loading article…
Security-Enhanced Linux ( SELinux ) は、Linux カーネルのセキュリティ モジュールであり、強制アクセス制御(MAC)を含むアクセス制御セキュリティ ポリシーをサポートするメカニズムを提供します。
SELinux は、さまざまなLinux ディストリビューションに追加されているカーネルの変更とユーザー空間ツールのセットです。そのアーキテクチャは、セキュリティ決定の強制をセキュリティ ポリシーから分離し、セキュリティ ポリシーの強制に関わるソフトウェアの量を合理化することを目指しています。[ 3 ] [ 4 ] SELinux の基盤となる主要な概念は、米国 国家安全保障局 (NSA)によるいくつかの以前のプロジェクトに遡ることができます。
NSAセキュリティ強化LinuxチームはNSA SELinuxを[ 5 ]と説明しています。
Linuxカーネルおよびユーティリティに対する一連のパッチにより、カーネルの主要サブシステムに強力かつ柔軟な強制アクセス制御（MAC）アーキテクチャが提供されます。これにより、機密性および完全性要件に基づく情報分離を強制する強化されたメカニズムが提供され、改ざんやアプリケーションセキュリティメカニズムの回避といった脅威に対処し、悪意のあるアプリケーションや欠陥のあるアプリケーションによって引き起こされる損害を限定することが可能になります。また、一般的なセキュリティ目標を満たすように設計された一連のサンプルセキュリティポリシー設定ファイルも含まれています。
SELinuxを統合したLinuxカーネルは、ユーザープログラムやシステムサービス、ファイルやネットワークリソースへのアクセスを制限する強制的なアクセス制御ポリシーを適用します。動作に必要な最小限の権限に制限することで、これらのプログラムやデーモンが不具合や侵害（例えばバッファオーバーフローや設定ミスなど）を起こした場合に、被害を与える可能性を低減または排除します。この制限メカニズムは、従来のLinuxの（任意）アクセス制御メカニズムとは独立して動作します。「root」スーパーユーザーの概念はなく、 setuid / setgidバイナリへの依存など、従来のLinuxセキュリティメカニズムによく見られる欠点もありません。
「変更されていない」Linuxシステム（SELinuxがインストールされていないシステム）のセキュリティは、カーネル、すべての特権アプリケーション、およびそれぞれの設定の正確性に依存します。これらのいずれかの領域に欠陥があると、システム全体が侵害される可能性があります。一方、「変更された」システム（SELinuxカーネルに基づくシステム）のセキュリティは、主にカーネルとそのセキュリティポリシー設定の正確性に依存します。アプリケーションの正確性や設定に問題があった場合、個々のユーザープログラムやシステムデーモンが限定的に侵害される可能性はありますが、他のユーザープログラムやシステムデーモン、あるいはシステム全体のセキュリティに対する脅威となるとは限りません。
純粋主義的な観点から見ると、SELinuxは、強制アクセス制御、強制整合性制御、ロールベースアクセス制御（RBAC）、および型強制アーキテクチャから得られた概念と機能を組み合わせたハイブリッドなソリューションを提供します。サードパーティ製のツールを使用することで、多様なセキュリティポリシーを構築できます。
UNIX（より正確にはPOSIX）コンピューティング環境内で、必須アクセス制御と任意アクセス制御（MACとDAC）を提供するアプローチを標準化するための初期の取り組みは、国家安全保障局のTrusted UNIX（TRUSIX）ワーキンググループによるもので、1987年から1991年にかけて会合を開き、Rainbow Book（#020A）を1冊出版し、形式モデルと関連する評価証拠プロトタイプ（#020B）を作成したが、これは最終的に出版されなかった。
SELinuxは、Linuxコミュニティに対し、強制的なアクセス制御の価値と、そのような制御をLinuxに追加する方法を示すために設計されました。当初、SELinuxを構成するパッチはLinuxカーネルのソースコードに明示的に適用する必要がありましたが、 Linuxカーネル2.6シリーズでメインラインに統合されました。
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）[ 7 ]を実装しています。このようなカーネルには、Flukeオペレーティングシステム[ 8 ]でプロトタイプ化されたアーキテクチャコンポーネントが含まれています。これらは、タイプ強制、ロールベースアクセス制御、マルチレベルセキュリティの概念に基づくものを含む、多くの種類の強制アクセス制御ポリシー[ 9 ]を強制するための一般的なサポートを提供します。FLASKは、強制アクセス制御システムに関する以前の研究の一部として開発されたMach由来の分散型信頼オペレーティングシステムであるDTOSに基づいています[ 10 ]。
SELinux のオリジナルおよび外部貢献者の包括的なリストは、2009 年のある時点でメンテナンスが停止されるまで NSA の Web サイトに掲載されていました。以下のリストは、インターネット アーカイブの Wayback Machine に保存されているオリジナルを再現したものです。貢献の範囲はページに記載されていましたが、簡潔にするために省略されています。ただし、アーカイブされたコピーからアクセスできます。[ 11 ]
SELinux のユーザーとロールは、実際のシステム ユーザーとロールと関連付ける必要はありません。SELinux は、現在実行中のすべてのユーザーまたはプロセスに対して、ユーザー名、ロール、ドメイン (またはタイプ) からなる 3 つの文字列コンテキストを割り当てます。このシステムは通常必要とされるよりも柔軟です。原則として、ほとんどの実際のユーザーは同じ SELinux ユーザー名を共有し、すべてのアクセス制御は 3 番目のタグであるドメインを通じて管理されます。プロセスが特定のドメインに入ることを許可する状況は、ポリシーで構成する必要があります。このコマンドは、runcon明示的に指定されたコンテキスト (ユーザー、ロール、ドメイン) にプロセスを起動することを可能にしますが、ポリシーで承認されていない場合は、SELinux は移行を拒否する可能性があります。
ファイル、ネットワークポート、その他のハードウェアにも、名前、役割（ほとんど使用されない）、およびタイプからなる SELinux コンテキストがあります。ファイルシステムの場合、ファイルとセキュリティコンテキスト間のマッピングはラベル付けと呼ばれます。ラベル付けはポリシーファイルで定義されますが、ポリシーを変更せずに手動で調整することもできます。ハードウェアタイプは非常に詳細で、たとえば、bin_t（/bin フォルダー内のすべてのファイル）やpostgresql_port_t（PostgreSQL ポート、5432）などです。リモートファイルシステムの SELinux コンテキストは、マウント時に明示的に指定できます。
SELinux は、-Zシェルコマンドls、psおよびその他いくつかのコマンドにスイッチを追加し、ファイルまたはプロセスのセキュリティ コンテキストを表示できるようにします。
一般的なポリシー規則は、明示的なアクセス許可で構成されます。例えば、ユーザーが特定の対象に対して特定のアクション（読み取り、実行、ネットワークポートの場合はバインドまたは接続）を実行するために、どのドメインのアクセス許可を持っている必要があるかなどです。役割やセキュリティレベルを含む、より複雑なマッピングも可能です。
一般的なポリシーは、ドメイン遷移を定義するマッピング（ラベル）ファイル、ルールファイル、およびインターフェースファイルで構成されます。これら3つのファイルは、SELinuxツールを使用してコンパイルし、単一のポリシーファイルを作成する必要があります。作成されたポリシーファイルは、カーネルにロードして有効にすることができます。ポリシーのロードとアンロードには再起動は必要ありません。ポリシーファイルは、手書きで作成することも、よりユーザーフレンドリーなSELinux管理ツールを使用して生成することもできます。通常、ポリシーファイルはまずパーミッシブモードでテストされます。このモードでは、違反はログに記録されますが、許可されます。audit2allowその後、ツールを使用して、ポリシーを拡張し、制限対象アプリケーションのすべての正当なアクティビティを許可する追加のルールを作成できます。
SELinuxの機能には以下が含まれます。
sestatusシステム（openSUSE Tumbleweed）におけるSELinuxの状態を表示するSELinuxはAndroidバージョン4.3以降に実装されています。 [ 16 ]
コミュニティがサポートする無料の Linux ディストリビューションの中で、Fedora は最も早く採用したディストリビューションの 1 つです。Fedora Core 2 以降はデフォルトでサポートされています。他のディストリビューションでは、Debian がバージョン 9 Stretch リリース以降[ 17 ]、Ubuntu が8.04 Hardy Heron 以降[ 18 ]でサポートされています。openSUSEはバージョン 11.1 以降、SELinux の「基本有効化」が含まれています。[ 19 ] SUSE Linux Enterprise (SLE) 11 では、SELinux が「テクノロジー プレビュー」として搭載されています。[ 20 ]
SELinuxは、 CoreOS Container LinuxやrktなどのLinuxコンテナベースのシステムで広く使われています。 [ 21 ]これは、デプロイされたコンテナとホスト間の分離をさらに強化するのに役立つ追加のセキュリティ制御として有用です。
SELinux は、2005 年以降、 Red Hat Enterprise Linux (RHEL) バージョン 4 およびそれ以降のすべてのリリースの一部として利用可能です。この存在は、 CentOS、Scientific Linux、AlmaLinux、Rocky Linuxなどの派生システムの対応するバージョンにも反映されています。RHEL4 でサポートされているポリシーは、最大限の使いやすさを目指したターゲット ポリシーであり、そのため、本来あるべきほど制限的ではありません。RHEL の将来のバージョンでは、ターゲット ポリシーのターゲットを増やすことが計画されており、より制限的なポリシーになります。RHEL バージョン 5 では、サーバー専用のマルチレベル セキュリティ(MLS) ポリシーが導入されました。Fedora Linux 10 では、メモリの少ないデバイスや仮想マシンなどの特定のプラットフォーム向けに設計された最小ポリシーが導入されました。[ 22 ]
openSUSE Tumbleweed は2025 年 2 月 11 日以降、新規インストールでAppArmorからSELinux に移行し、SLE/openSUSE Leap 16 もデフォルトで SELinux を搭載して出荷されました。[ 23 ] openSUSE/SLE は、SELinux の実装に RHEL/Fedora のポリシーを採用しましたが、いくつかの違いがあります。[ 24 ] AppArmor は、既存の Tumbleweed および SLE/openSUSE Leap 15.x インストール用に保持されています (ユーザーは、既存のインストールを手動で SELinux に移行できます)。AppArmor は、Tumbleweed ユーザーのインストール時の選択肢としても利用できますが、SLE/Leap 16 では利用できません。[ 25 ] [ 26 ]
SELinuxは、システム上で各ユーザー、プロセス、デーモンに対して許可されるアクティビティを、非常に詳細な仕様に基づいて制御できます。データベースエンジンやWebサーバーなど、データアクセス権限やアクティビティ権限が明確に定義されているデーモンを制限するために使用されます。これにより、制限されたデーモンが侵害された場合の潜在的な被害を軽減できます。
コマンドラインユーティリティには、[ 27 ]chcon、[ 28 ]restorecon、[ 29 ]restorecond、[ 30 ]runcon、[ 31 ]secon、[ 32 ]fixfiles、[ 33 ]setfiles、[ 34 ]load_policy、[ 35 ]booleans、[ 36 ]getsebool、[ 37 ]setsebool、[ 38 ] 、 togglesebool[ 39 ] 、 [ 40 ]、[ 41 ]、[ 42 ] が含ま れ ます 。setenforcesemodulepostfix-nochrootcheck-selinux-installationsemodule_packagecheckmoduleselinux-config-enforcingselinuxenabledselinux-policy-upgrade
SELinuxを強制モードにするには：
setenforce 1SELinuxの状態を照会するには：
getenforceSELinux represents one of several possible approaches to the problem of restricting the actions that installed software can take. Another popular alternative is called AppArmor and is available on SUSE Linux Enterprise Server (SLES) (before Version 16), openSUSE, and Debian-based platforms. AppArmor was developed as a component to the now-defunct Immunix Linux platform. Because AppArmor and SELinux differ radically from one another, they form distinct alternatives for software control. Whereas SELinux re-invents certain concepts to provide access to a more expressive set of policy choices, AppArmor was designed to be simple by extending the same administrative semantics used for DAC up to the mandatory access control level.
There are several key differences:
CAP_FOWNERまたはを与えますCAP_DAC_OVERRIDE。SELinux では、管理者（またはプラットフォームベンダー）は、SELinux を構成して、本来は制限されていないユーザーに対してすべての機能を拒否し、従業員がログイン後に移行できる制限付きドメインを作成できます。このドメインでは、適切なタイプのファイルに対してのみ、これらの機能を行使できます。プロセスの分離は、仮想化などのメカニズムによっても実現できる。
NSAは、セキュリティ強化AndroidでSELinuxの概念の一部を採用している。[ 45 ]
General Dynamicsは、Red Hat Enterprise Linux向けのマルチレベルセキュリティ（MLS）拡張機能であるPitBull Trusted Operating System [ 46 ]を構築および配布しています。
マルチカテゴリセキュリティ（MCS）は、Red Hat Enterprise Linuxの SELinux の拡張機能であり、ユーザーがファイルにカテゴリのラベルを付けることで、裁量アクセス制御とタイプ強制によるアクセス制限をさらに強化できます。カテゴリは、マルチレベルセキュリティ（MLS）で使用される機密レベル内に追加の区画を提供します。 [ 47 ]
は、セキュリティ強化版 Linux オペレーティングシステムのプロトタイプ版を開発し、一般に公開することを発表します。
アクセスを許可するか拒否するかといったSELinuxの決定はキャッシュされます。このキャッシュはアクセスベクトルキャッシュ（AVC）と呼ばれます。決定をキャッシュすることでSELinuxルールのチェック頻度が減り、パフォーマンスが向上します。
警告: AppArmor は SUSE Linux Enterprise 16.0 では利用できなくなりました。Leap ユーザーは、新規インストール時に AppArmor を Linux セキュリティ モジュール (LSM) として選択できません。AppArmor はインストール後に有効にすることができます。