SELINUXの動作原理の詳細な説明

1. はじめに

SELinux が Linux にもたらす主な価値は、柔軟で構成可能な MAC メカニズムを提供することです。

Security-Enhanced Linux (SELinux) は、次の 2 つの部分で構成されています。

1) カーネル SELinux モジュール (/kernel/security/selinux)

2) ユーザーモードツール

SELinux は、LSM (Linux セキュリティモジュール) フレームワークを通じて Linux カーネル 2.6.x に統合されたセキュリティアーキテクチャです。これは、NSA (米国国家安全保障局) と SELinux コミュニティの共同プロジェクトです。

SELinux は柔軟な強制アクセス制御 (MAC) システムを提供し、Linux カーネルに組み込まれています。 SELinux は、システム内の各ユーザー、プロセス、アプリケーション、およびファイルのアクセス権限と変更権限を定義し、セキュリティポリシーを使用してこれらのエンティティ (ユーザー、プロセス、アプリケーション、およびファイル) 間のやり取りを制御します。セキュリティポリシーは、厳密なチェック方法と緩いチェック方法を指定します。

SELinux はシステムユーザーに対して透過的であり、システム管理者のみがサーバー内で厳格なポリシーを策定する方法を検討する必要があります。ポリシーは必要に応じて厳しくしたり緩めたりすることができます。

サブジェクトは、[標準 Linux アクセス制御] と [SELinux アクセス制御] の両方が満たされている場合にのみオブジェクトにアクセスできます。

1.1 DACとMAC（ルートユーザー）の主な違い

Security Enhanced Linux (SELinux) は、もともと NSA (国家安全保障局) によって開始され、アプリケーションが必要な最小限の権限で実行できるようにするコアコンポーネントとユーザーツールのセットとして Linux システムに追加されました。改変されていない Linux システムでは、ユーザーが自分でより高い権限を要求できる任意アクセス制御が使用されるため、マルウェアはほぼすべてのファイルにアクセスでき、ルート権限を与えれば何でも実行できます。

SELinux にはルートの概念はありません。セキュリティポリシーは管理者によって定義され、ソフトウェアによって置き換えることはできません。つまり、潜在的なマルウェアが引き起こす可能性のある被害を最小限に抑えることができます。一般的に言えば、データセキュリティを非常に重視するエンタープライズレベルのユーザーのみが SELinux を使用します。

オペレーティングシステムには、任意アクセス制御 (DAC) と強制アクセス制御 (MAC) の 2 種類のアクセス制御があります。標準的な Linux セキュリティは DAC ですが、SELinux は Linux に柔軟で構成可能な MAC を追加します。

すべての DAC メカニズムには共通の弱点があります。それは、自然人とコンピュータプログラム間の最も基本的な違いを認識できないことです。簡単に言えば、ユーザーにアクセス権限が与えられているということは、プログラムにもアクセス権限が与えられているということです。プログラムにアクセス権限が与えられている場合は、悪意のあるプログラムにも同じアクセス権が与えられます。 DAC の根本的な弱点は、対象がさまざまなマルウェア攻撃に対して脆弱であることです。MAC はこれらの攻撃を回避する方法です。ほとんどの MAC 機能は、多層セキュリティモデルを形成します。

SELinux は、Type Enforcement と呼ばれるより柔軟な MAC フォームと、必須ではないマルチレベルセキュリティフォームを実装します。

Android 4.2 では、SELinux はオプション機能であり、Google はルート権限やその他の機能を直接キャンセルしませんでした。これは、エンタープライズレベルのユーザーやプライバシーデータを重視するユーザー向けに提供されるオプションです。一般消費者はこれを完全にオフにすることができます。

2. SELinuxの動作メカニズム

SELinux の決定プロセスを次の図に示します。

サブジェクト (アプリケーションなど) がオブジェクト (ファイルなど) にアクセスしようとすると、カーネル内のポリシー適用サーバーは、サブジェクトとオブジェクトの権限がキャッシュされている AVC (アクセスベクターキャッシュ) をチェックします。 AVC のデータに基づいて決定できない場合は、セキュリティサーバーに要求が送信され、セキュリティサーバーはマトリックス内の「アプリケーション + ファイル」のセキュリティ環境を検索します。クエリ結果に基づいてアクセスが許可または拒否され、拒否メッセージの詳細は /var/log/messages に保存されます。

3. SELinux疑似ファイルシステム

/selinux/ 疑似ファイルシステムはカーネルサブシステムでよく使用されるコマンドであり、/proc/ 疑似ファイルシステムに似ています。システム管理者およびユーザーはこの部分を操作する必要はありません。 /selinux/ ディレクトリの例は次のとおりです。

-rw-rw-rw- 1 ルート ルート 0 9月22日 13:14 アクセス 
dr-xr-xr-x 1 ルート ルート 0 9月22日 13:14 ブール値 
--w------ 1 ルート ルート 0 9月22日 13:14 commit_pending_bools 
-rw-rw-rw- 1 ルート ルート 0 9月22日 13:14 コンテキスト 
-rw-rw-rw- 1 ルート ルート 0 9月22日 13:14 作成 
--w------ 1 root root 0 9月22日 13:14 無効 
-rw-r--r-- 1 ルート ルート 0 9月22日 13:14 強制 
-rw------ 1 ルート ルート 0 9月22日 13:14 ロード 
-r--r--r-- 1 ルート ルート 0 9月22日 13:14 mls 
-r--r--r-- 1 ルート ルート 0 9月22日 13:14 policyvers 
-rw-rw-rw- 1 ルート ルート 0 9月22日 13:14 ラベル変更 
-rw-rw-rw- 1 ルート ルート 0 9月22日 13:14 ユーザー

たとえば、cat の強制値は次のようになります。

1: 強制モード

0: 許可モード

4. SELinux 設定ファイル

SELinux 構成ファイルまたはポリシーファイルは、/etc/ ディレクトリにあります。

4.1 /etc/sysconfig/selinux 設定ファイル

/etc/sysconfig/selinux はシンボリックリンクです。実際の設定ファイルは /etc/selinux/config です。

SELinux を設定するには 2 つの方法があります。

1) 設定ツールを使用する: セキュリティレベル設定ツール (system-config-selinux)

2) 設定ファイル (/etc/sysconfig/selinux) を編集します。
/etc/sysconfig/selinux には次の設定オプションが含まれています。

1) SELinuxを有効または無効にする

2) システムが実行するポリシーを設定する

3) システムがポリシーを実行する方法を設定する

4.2 設定ファイルのオプション

4.2.1 カーネル

SELINUX=enforcing|permissive|disabled — SELinuxの高度な状態を定義します

enforcing — SELinux セキュリティポリシーが適用されます。
permissive — SELinux システムは警告を出力しますが、ポリシーは適用しません。
disabled — SELinux は完全に無効です。SELinux フックはカーネルから解除され、疑似ファイルシステムは登録解除されます。

4.2.2 SELINUXTYPE（セキュリティポリシー）

SELINUXTYPE=targeted|strict — 適用するSELinuxポリシーを指定します

対象 — 対象となるネットワークデーモンのみが保護されます。各デーモンがポリシーを実行するかどうかは、system-config-selinux を通じて設定できます。一般的なネットワークサービスを保護します。これは SELinux のデフォルト値です。

次のツールを使用して、各デーモンのブール値を設定できます。

1) getsebool -a: すべてのSELinuxブール値を一覧表示する

2) setsebool: SELinux ブール値を設定します。例: setsebool -P dhcpd_disable_trans=0。-P は、再起動後もブール値が有効であることを意味します。

strict — SELinux の完全な保護を強制します。すべてのサブジェクトとオブジェクトのセキュリティコンテキストを定義し、各アクションはポリシー実行サーバーによって処理されます。ロールベースアクセス制御 (RBAC) に準拠し、ネットワークサービス、一般的なコマンド、およびアプリケーションを保護するための完全な保護機能を備えたポリシーを提供します。

4.2.3 SETLOCALDEFS

SETLOCALDEFS=0|1 — ローカル定義の設定方法を制御します (ユーザーとブール値)。

1: これらの定義は、/etc/selinux/<policyname>ファイルから取得されるload_policyによって制御されます。
0: semanage によって制御されます

4.3 /etc/selinux/ ディレクトリ

/etc/selinux/ は、すべてのポリシーファイルと主要な構成ファイルが保存されるディレクトリです。例は以下のとおりです。

-rw-r--r-- 1 ルート ルート 448 9月 22 17:34 config 
drwxr-xr-x 5 ルート ルート 4096 9月22日 17:27 厳密 
drwxr-xr-x 5 ルート ルート 4096 9月22日 17:28 対象

5. SELinuxツール

1) /usr/sbin/setenforce — SELinux の動作モードを変更します。例は次のとおりです。

setenforce 1 — SELinux は強制モードで実行されます
setenforce 0 — SELinux は警告 (許可) モードで実行されます

SELinuxを無効にするには、設定ファイル/etc/selinux/configまたは/etc/sysconfig/selinuxを変更します。

2) /usr/sbin/sestatus -v — 以下に示すように、詳細なシステムステータスを表示します。

SELinux ステータス: 有効 
SELinuxfs マウント: /selinux 
現在のモード: 強制 
設定ファイルからのモード: 強制 
ポリシーバージョン: 21 
設定ファイルからのポリシー: 対象 
プロセスコンテキスト: 
現在のコンテキスト: user_u:system_r:unconfined_t:s0 
初期化コンテキスト: system_u:system_r:init_t:s0 
/sbin/mingetty システム_u:システム_r:getty_t:s0

3) /usr/bin/newrole — 新しいコンテキストまたはロールで新しいシェルを実行します

4) /sbin/restorecon — 適切なファイルまたはセキュリティ環境に拡張属性をマークして、1つまたは複数のファイルのセキュリティ環境を設定します。

5) /sbin/fixfiles — ファイルシステム内のセキュリティ環境データベースをチェックまたは修正する

6) getsebool — getsebool -a: すべてのブール値を表示

7) setsebool — パラメータ -P、永続的な設定

8) chconはファイルとディレクトリのセキュリティコンテキストを変更します

chcon –u [ユーザー]
chcon –r [役割]
chcon –t [タイプ]
chcon –R 再帰

6. 型強制セキュリティコンテキスト

セキュリティコンテキストは、シンプルで一貫性のあるアクセス制御属性です。SELinux では、タイプ識別子がセキュリティコンテキストの主な構成要素です。歴史的な理由から、プロセスのタイプはドメインと呼ばれることがよくあります。「ドメイン」と「ドメインタイプ」は同じ意味です。厳密に区別したり、ドメインという用語の使用を避けたりする必要はありません。通常、[ドメイン]、[ドメインタイプ]、[サブジェクトタイプ]、[プロセスタイプ] は同義語、つまりセキュリティコンテキストではすべて「タイプ」であると考えられます。

SELinux は、オブジェクトとサブジェクトのセキュリティコンテキストを表示するための -Z オプションを追加することで、システム内の多くのコマンドを変更します。

1) システムは、PAM サブシステムの pam_selinux.so モジュールに基づいて、ログオンユーザーが実行するプログラムのセキュリティコンテキストを設定します。
2) ファイルのセキュリティコンテキストルールは次のとおりです。

rpm パッケージがインストールされている場合、セキュリティコンテキストは rpm パッケージ内のレコードに従って生成されます。
手動で作成されたファイル: セキュリティコンテキストはポリシーに従って設定されます。
cp: セキュリティコンテキストを再生成します。
mv: セキュリティコンテキストは変更されません。

3) id -Z

シェルのセキュリティコンテキストを表示します。

4) ps -Z

プロセスのセキュリティコンテキストを確認します。

5) ls -Z

ファイルとディレクトリのセキュリティコンテキストを確認します。

6.1 セキュリティコンテキストフォーマット

すべてのオペレーティングシステムのアクセス制御は、関連付けられたオブジェクトとサブジェクトに対する何らかのタイプのアクセス制御属性に基づいています。 SELinux では、アクセス制御属性はセキュリティコンテキストと呼ばれます。すべてのオブジェクト (ファイル、プロセス間通信チャネル、ソケット、ネットワークホストなど) とサブジェクト (プロセス) には、セキュリティコンテキストが関連付けられています。セキュリティコンテキストは、ユーザー、ロール、およびタイプ識別子の 3 つの部分で構成されます。セキュリティコンテキストは通常、次の形式で指定または表示されます。

USER：ROLE：TYPE[LEVEL[：CATEGORY]]

セキュリティコンテキスト内のユーザーおよびロール識別子は、強制に対するわずかな制約を除き、タイプ強制アクセス制御ポリシーにほとんど影響しません。プロセスの場合、ユーザーおよびロール識別子は、Linux ユーザーアカウントに関連付けられているタイプおよびユーザー識別子の結合を制御するために使用されるため、より意味があります。ただし、オブジェクトの場合、ユーザーおよびロール識別子はほとんど使用されません。標準化された管理では、オブジェクトのロールは多くの場合 object_r であり、オブジェクトのユーザーは多くの場合、オブジェクトを作成したプロセスのユーザー識別子です。これらはアクセス制御にほとんど影響しません。

標準の Linux セキュリティにおけるユーザー ID とセキュリティコンテキストにおけるユーザー識別子の違いは、技術的に言えば、それぞれ標準およびセキュリティ強化アクセス制御メカニズムに使用される直交識別子であり、両者の相関関係は SELinux ポリシーによって直接強制されるのではなく、ログオンプロセスによって厳密に決定されることです。

6.1.1 ユーザー
1) ユーザー ID: Linux システムの UID と同様に、ID 識別を提供し、ID を記録するために使用されます。セキュリティコンテキストの一部です。
2) 一般的な 3 つのユーザータイプ:

user_u : システムにログインした後の一般ユーザーのデフォルト設定。
system_u : 起動時のシステムプロセスのデフォルト設定。
root : root ログイン後のデフォルト。

3) 対象を絞った政策ではユーザーはそれほど重要ではない。
4) 厳格なポリシーではさらに重要なことですが、root を除くすべてのデフォルトの SELinux ユーザーは「_u」で終わります。

6.1.2 役割

1) ファイル、ディレクトリ、デバイスの役割: 通常は object_r。
2) プログラムの役割: 通常は system_r。
3) ユーザーロール: 対象ポリシーは system_r、厳密なポリシーは sysadm_r、staff_r、user_r です。ユーザーロールはシステム内の GID に似ており、異なるロールには異なる権限があります。ユーザーは複数のロールを持つことができますが、同時に使用できるロールは 1 つだけです。

4) ロール情報を保存するには、RBAC（ロールベースアクセス制御）に基づく厳密なMLSポリシーを使用する

6.1.3 タイプ

1) タイプ: サブジェクトとオブジェクトを異なるグループに分割し、システム内の各サブジェクトとオブジェクトのタイプを定義し、プロセス操作に最も低い権限環境を提供するために使用されます。
2) 実行中のプロセスに型が関連付けられている場合、その型はドメインとも呼ばれます。
3) type は SELinux セキュリティコンテキストの最も重要な部分であり、SELinux Type Enforcement の中核です。デフォルト値は _t で終わります。

レベルとカテゴリ: レベルとカテゴリを定義します。MLS 戦略でのみ使用されます。

LEVEL: セキュリティレベルを表します。現在定義されているセキュリティレベルは s0 ～ s15 で、レベルが上がるにつれて増加します。
CATEGORY: カテゴリを表します。現在定義されているカテゴリはc0-c1023です。

6.2 SELinux と標準 Linux アクセス制御属性の比較

標準 Linux では、サブジェクトのアクセス制御属性は、カーネル内のプロセス構造を通じてプロセスに関連付けられた実際の有効なユーザー ID とグループ ID です。これらの属性は、ログインプロセスや setuid プログラムなどのさまざまなツールを使用してカーネルによって保護されます。オブジェクト (ファイルなど) の場合、ファイルの inode には、アクセスモードビットのセット、ファイルのユーザー ID とグループ ID が含まれます。以前のアクセス制御は、読み取り/書き込み/実行の 3 つの制御ビットに基づいており、1 つはファイル所有者用、1 つはファイル所有者が所属するグループ用、1 つはその他用に設定されていました。

SELinux では、アクセス制御属性は常にセキュリティコンテキストトリプレット (ユーザー:ロール:タイプ) の形式であり、すべてのオブジェクトとサブジェクトには関連付けられたセキュリティコンテキストがあります。 SELinux の主なアクセス制御機能はタイプの強制であるため、セキュリティコンテキスト内のタイプ識別子によってアクセス権が決定されることに注意することが重要です。

注: SELinux は標準 Linux にタイプ強制 (TE) を追加します。つまり、オブジェクトにアクセスするには、まず標準 Linux と SELinux の両方のアクセス制御を満たす必要があります。たとえば、ファイルに対する SELinux 書き込み権限があっても、そのファイルに対する w 権限がない場合は、そのファイルに書き込むことはできません。次の表は、標準 Linux と SELinux のアクセス制御属性の比較をまとめたものです。

標準Linux
SELInux

プロセスセキュリティ属性の実ユーザーおよび実効ユーザーとグループ ID
セキュリティコンテキスト

オブジェクトのセキュリティ属性アクセスモード、ファイルユーザーおよびグループID
セキュリティコンテキスト

プロセスユーザー/グループIDとファイルアクセスモードに基づくアクセス制御、
このアクセスモードはファイルのユーザー/グループIDに基づいています
プロセスタイプとファイルタイプ間で許可される権限

6.3 まとめ

1) システム内の各ファイル、ディレクトリ、ネットワークポートなどにはセキュリティコンテキストが割り当てられ、ポリシーによってセキュリティコンテキスト間の相互作用のルールが規定されます。
2) SELinux は、ポリシーとセキュリティコンテキストルールに基づいてアクセス動作が実行可能かどうかを決定します。
3) 件名: /usr/sbin/httpd などのシステムプロセス。
4) オブジェクト: ファイル、ディレクトリ、IP、ソケットなど、アクセス対象の項目。

7. タイプエンフォースメント（TE）アクセス制御

SELinux では、すべてのアクセスを明示的に承認する必要があり、Linux ユーザー/グループ ID に関係なく、SELinux はデフォルトではアクセスを許可しません。つまり、SELinux にはデフォルトのスーパーユーザーは存在しません。標準 Linux のルートとは異なり、サブジェクトタイプ (ドメインなど) とオブジェクトタイプを指定して、許可ルールを使用してアクセス権が付与されます。許可ルールは、次の 4 つの部分で構成されます。

ソースタイプは通常、アクセスしようとしているプロセスのドメインタイプです。
ターゲットタイププロセスがアクセスするオブジェクトのタイプ
オブジェクトクラスは、アクセスが許可されるオブジェクトのタイプを指定します。
権限は、ターゲットタイプがソースタイプにオブジェクトタイプへのアクセスを許可するアクセスのタイプを示します。

以下にいくつか例を挙げます。

user_t bin_t : ファイル {読み取り、getattr の実行} を許可します。

この例では、ソースタイプ (またはサブジェクトタイプまたはドメイン) user_t とターゲットタイプ (またはオブジェクトタイプ) bin_t の 2 つのタイプ識別子を含む TE 許可ルールの基本構文を示します。識別子ファイルは、ポリシーで定義されたオブジェクトクラスの名前です (この場合は通常のファイル)。中括弧で囲まれた権限は、ファイルオブジェクトクラスの有効な権限のサブセットです。このルールは次のように解釈されます。

ドメインタイプが user_t のプロセスは、タイプが bin_t のファイルオブジェクトの読み取り/実行や属性の取得を行うことができます。

前の例のような SELinux の allow ルールは、実際に SELinux でアクセス権を付与します。実際の課題は、何万ものアクセスが正しく承認され、最大限のセキュリティを実現するために必要な権限のみを付与できるようにすることです。

7.1 標準 Linux セキュリティにおける setuid プログラム

知識豊富なユーザー joe は、既存のパスワードを安全に変更したいと考えています。Linux では、passwd に setuid 値を与えて、ルート権限で実行できるようにすることでこの問題を解決しています。通常の Linux システムでパスワードファイルを一覧表示すると、次のようになります。

# ls -l /usr/bin/passwd
-rwsr-xr-x. 1 ルート ルート 41292 2012年9月7日 /usr/bin/passwd

ここで 2 つの点に注意してください。1 つ目は、所有者権限の x 位置が s に設定されていることです。これはいわゆる setuid ビットで、このファイルを実行するすべてのプロセスの有効な UID (ユーザー ID) がファイル所有者の UID に変更されることを意味します。ここで、root はファイルの所有者であるため、パスワードプログラムが実行されると、実際には root ユーザー ID として実行されます。実行プロセスを次の図に示します。

上記の分析から、passwd はルート権限で実行されることがわかります。システムのあらゆるリソースにアクセスできるため、システムにセキュリティ上の問題が生じます。実際、アクセスする必要があるのは shadow とその関連ファイルだけです。そして、shadow は passwd からのアクセスのみを受け入れる必要があります。これは標準の Linux では不可能ですが、TE (type enhancement) を使用するとこの機能を実現できます。

8. ロールベースのアクセス制御

SELinux は、ロールベースのアクセス制御 (RBAC) も提供します。SELinux の RBAC 機能は、タイプ強制に基づいています。SELinux のアクセス制御は、主にタイプを通じて実装されます。ロールは、プロセスセキュリティコンテキストのロール識別子に基づいて、プロセスが変換できるタイプを制限します。このようにして、ポリシー作成者は、一連のドメインタイプに変換できるロールを作成し (タイプ強制ルールが変換を許可していると仮定)、ロールの制限を定義できます。

9. SELinux のマルチレベルセキュリティ

タイプ強制は、SELinux によって導入された最も重要な強制アクセス制御 (MAC) メカニズムであることは間違いありません。ただし、主に機密性制御アプリケーションのサブセットでは、従来のマルチレベルセキュリティ (MLS) MAC をタイプ強制と組み合わせて使用するとより価値が高まります。このような場合、SELinux には常に何らかの形の MLS 機能が含まれます。MLS 機能はオプションです。SELinux の 2 つの MAC メカニズムのうち、MLS は通常最も重要なものではありません。多くの非機密データアプリケーションを含む、ほとんどの安全なアプリケーションでは、タイプ強制が最も適したセキュリティ強化メカニズムです。ただし、MLS は一部のアプリケーションのセキュリティを強化します。

ほとんどの SELinux ポリシーでは、機密性 (s0、s1、...) とカテゴリ (c0、c1、...) にワイルドカード名が使用され、意味のあるユーザー名の指定はユーザー空間プログラムとライブラリに任されます。 (たとえば、s0 は UNCLASSIFIED に関連付けられ、s1 は SECRET に関連付けられる可能性があります)
MLS をサポートするために、セキュリティコンテキストが拡張され、次のようなセキュリティレベルが含まれるようになりました。

ユーザー:ロール:タイプ:感度[:カテゴリ,...] [-感度[:カテゴリ,...]]

次の例は例を示しています。

root@luohj-仮想マシン:~# ps -aZ 
ラベル PID TTY 時間 コマンド 
unconfined_u:system_r:insmod_t:s0-s0:c0.c255 4940 ポイント/0 00:00:00 パスワード

MLS セキュリティコンテキストには、少なくとも 1 つのセキュリティレベル (単一の機密性と 0 個以上のカテゴリで構成) が必要ですが、低 (またはプロセストレンド) と高 (またはプロセスギャップ) という 2 つのセキュリティレベルを含めることができます。高セキュリティレベルがない場合、低セキュリティレベルと同じであると見なされます (最も一般的なケース)。実際には、低セキュリティレベルと高セキュリティレベルは、通常、オブジェクトとプロセスで同じです。プロセスによく使用されるレベル範囲は、信頼されたサブジェクト (つまり、プロセス信頼ダウングレード情報) またはディレクトリなどの異なるセキュリティレベルのオブジェクトを含むマルチレイヤーオブジェクトであると見なされます。説明を簡単にするために、すべてのプロセスとオブジェクトには 1 つのセキュリティレベルのみがあると想定します。

10. 戦略分析ツール apol

apol (ポリシー分析) ツールは、setools ツールキット内にある成熟した SELinux ポリシー分析ツールです。これを使用して policy.xx ファイルを開き、関連するすべてのポリシーを分析します。 xx はポリシーコンパイラ (checkpolicy) のバージョン番号です。

11. まとめ

SELinux アクセス制御は、すべてのシステムリソース (プロセスを含む) に関連付けられたセキュリティコンテキストに基づいています。セキュリティコンテキストは、ユーザー、ロール、およびタイプ識別子の 3 つのコンポーネントで構成されます。タイプ識別子はアクセス制御の主な基礎となります。

SELinux におけるアクセス制御の主な特徴は、サブジェクト (プロセス) とオブジェクト間のアクセス許可を、許可ルール (サブジェクトのタイプ (ドメインタイプとも呼ばれる) がソース、オブジェクトのタイプがターゲット) を指定して行うタイプ強制です。特定のオブジェクトカテゴリに対してアクセスを許可し、オブジェクトカテゴリごとにきめ細かな権限を設定します。

タイプ強制の主な利点は、特定のドメインタイプで実行できるプログラムを制御できることです。したがって、個々のプログラムに対するアクセス制御が可能になります (ユーザーレベルのセキュリティ制御よりもはるかに安全です)。プログラムが別のドメインに入ること (つまり、特定のプロセスタイプとして実行すること) を有効にすることをドメイン遷移と呼び、SELinux の許可ルールによって厳密に制御されます。SELinux では、type_transition ファイルによってドメイン遷移を自動的に実行することもできます。

SELinux は、アクセス制御セキュリティコンテキストでロール識別子を直接使用しません。代わりに、すべてのアクセスはタイプベースであり、ロールは許可されたドメインタイプを関連付けるために使用されます。これにより、タイプが強制される許可された機能をグループ化し、ユーザーをロールとして認証できます。

SELinux は、より多くのアクセス制限を提供するオプションの MLS アクセス制御メカニズムを提供します。MLS 機能は TE メカニズムに基づいて構築されています。MLS は、セキュリティコンテキストの内容を拡張して、現在の (または低い) セキュリティレベルとオプションの高セキュリティレベルを含めます。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。

以下もご興味があるかもしれません: