【Linuxの基礎知識】SELinuxの仕組みとトラブル対応

Linuxを触っていると「SELinuxが原因で動かない」という場面に出会ったことはありませんか。

初めて遭遇すると「なんで権限も設定したのに拒否されるんだ？」と混乱するはずです。

ファイルのパーミッションや所有者を確認しても問題が見当たらないのに、なぜかアクセスがブロックされる。

実はそれ、SELinuxが裏でしっかり監視しているからです。

SELinuxはLinuxカーネルに組み込まれた強力なセキュリティ機構で、通常のUNIXパーミッションやACLとは別に、ポリシーに基づいて細かくアクセス制御を行います。

だからこそ強固な防御壁となる一方で、設定や仕組みを理解していないと「謎の不具合」として立ちはだかります。

本記事ではSELinuxの仕組みを整理しつつ、トラブル対応の基本的な流れを具体的に解説します。セキュリティを保ちつつシステムを安定運用するための第一歩を一緒に確認していきましょう。

SELinuxとは

Linuxを利用する上で「権限は正しいはずなのにアクセスできない」という状況に遭遇することがあります。

これはSELinux（Security-Enhanced Linux）が強制アクセス制御を行っているためです。SELinuxはカーネルレベルで動作するセキュリティ機構であり、ファイルパーミッションやACLとは異なる観点からセキュリティを実現します。

仕組みを理解することで、トラブル発生時の切り分けが容易になり、システムを安定的に運用できます。

基本概要

SELinuxはアメリカ国家安全保障局（NSA）が中心となって開発されたアクセス制御機構です。Linuxカーネルに統合されており、従来の「ユーザー・グループ・その他」という権限管理に加えて、より細かいルールでアクセスを制御します。

標準的なLinuxではroot権限を持つユーザーはほぼすべての操作が可能ですが、SELinuxはrootであってもポリシー違反の操作を拒否できます。

結局何が他のセキュリティーと違う？

LInuxのセキュリティ関連は色々あって結局何が違うのかわからないことが多すぎますよね。

SELinuxの最大の特徴は、従来のLinuxセキュリティ（パーミッションやACL）と違い、「強制アクセス制御（MAC: Mandatory Access Control）」をOSレベルで適用する点にあります。

違いを整理するとこうなります：

仕組み	特徴	弱点
パーミッション（rwx）	ユーザー／グループ単位でアクセス制御	root権限を取られると無効化される
ACL	ユーザーやグループごとに細かく権限を設定可能	結局rootが全てを変更可能
SELinux	プロセスやファイルに「ラベル」を付与し、ポリシーでアクセスを強制的に制御	設定が複雑で誤設定しやすい

SELinuxが他と決定的に違うのは、rootでさえポリシーを超えることはできないことです。

• 攻撃者がrootを奪取しても、SELinuxポリシーが壁となって横展開できない
• プロセスごとにアクセス範囲を制御できるため、侵入が起きても被害を局所化できる
• 規制や監査要件（PCI DSSなど）を満たせる

つまり「通常のセキュリティが“誰に何を許可するか”なのに対し、SELinuxは“プロセスごとに何ができるかを強制的に縛る”」という仕組みが、他と決定的に違う点です。

ACL（アクセス制御リスト）が「誰が何をできるか」を柔軟に設定する仕組みなのに対して、SELinuxは 強制アクセス制御（MAC） を採用しており、プロセスやリソースに「セキュリティコンテキスト（ラベル）」を付け、それに基づいてアクセスを判定します。




つまり「ACLに似た仕組みをOSレベルで強制的に適用し、モードによって“遮断するか”“ログを残すか”を切り替える」仕組みがSELinuxです。

この仕組みによって、万が一の侵入時にも被害を最小限に抑えることができます。

アクセス制御モデル（MACとDACの違い）

Linuxにおける従来のアクセス制御はDAC（任意アクセス制御, Discretionary Access Control）と呼ばれ、ファイル所有者がアクセス権を決定します。

一方、SELinuxはMAC（強制アクセス制御, Mandatory Access Control）を採用しており、システム全体に対してセキュリティポリシーを強制的に適用します。

制御モデル	概要	特徴
DAC（任意アクセス制御）	ファイル所有者がアクセス権を決定	柔軟だが管理者権限に弱い
MAC（強制アクセス制御）	システム全体でルールを強制	root権限でも違反操作は拒否

この違いにより、SELinuxはより強固なセキュリティを実現できる反面、正しく理解していないと「なぜか動かない」という問題に直面しやすくなります。

SELinuxが収集・制御する情報

SELinuxはアクセス制御の判断を行うために、対象となるプロセスやファイルに「セキュリティコンテキスト」という情報を付与します。

セキュリティコンテキストはユーザー、ロール、タイプなどで構成され、アクセスの可否を細かく制御します。

ls -Z /var/www/html/

出力例:

-rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 index.html

この例では「httpd_sys_content_t」というタイプが割り当てられており、Apache(httpd)プロセスがアクセス可能な領域であることを示しています。

もし誤ったコンテキストが設定されていれば、正しいパーミッションであってもアクセスが拒否されます。これがSELinux特有の制御の仕組みです。

昔は無効化が常識だったSELinuxの扱いの変化

かつてRHEL5やRHEL6の時代では、SELinuxは「まず無効化するもの」として扱われることが一般的でした。

当時のSELinuxはポリシーが未成熟で、Webサーバーやデータベースといった基本サービスでさえも正しく動作しないことが多く、原因切り分けに時間がかかりました。

現場ではトラブルを避けるために最初にSELinuxをDisabledへ変更することが半ば常識となっていたのです。

しかしRHEL8以降では状況が大きく変化しました。

主要なサービスは標準ポリシーで安定して動作し、semanageやrestoreconなどの補助ツールによってトラブル対応もしやすくなっています。

さらに、セキュリティ要求が強化される現代においては、PCI DSSや金融・公共システムの基準でSELinuxの有効化が必須となっています。

Red Hat公式のガイドラインでも、Disabledは推奨されず、Enforcingでの運用を基本とすることが明示されています。

このように、かつては「切るのが当たり前」だったSELinuxは、今では「有効化して使うのが当たり前」へと大きく変化しているのです。

SELinuxを利用する意義

SELinuxの最大の意義は、従来のUNIXパーミッションやACLでは防ぎきれない攻撃や操作を制御できる点にあります。

通常のDAC（任意アクセス制御）はユーザーやグループ単位の制御しかできず、root権限を取得された場合には防御が突破されてしまいます。しかしSELinuxはMAC（強制アクセス制御）を採用しているため、root権限であってもポリシー違反の操作は拒否されます。

例えば、Webサーバーのhttpdプロセスが侵入を受けても、そのプロセスがアクセスできるのはhttpd_sys_content_tのラベル（後述）が付いたファイルに限定されます。システム全体やデータベースファイルにまで不正アクセスが広がることはありません。

このように、SELinuxを利用することで「突破されても被害を最小化する」という仕組みが働き、サーバー運用の最後の防御線として機能します。単なるアクセス制御の強化にとどまらず、現代的なセキュリティ要件を満たす上で欠かせない存在となっているのです。

SELinuxのラベルとセキュリティコンテキスト

SELinuxは、ファイルやプロセスに「ラベル（セキュリティコンテキスト）」を付与し、その組み合わせでアクセス制御を行います。ラベルは次の要素で構成されます。

要素	意味	例
ユーザー	SELinux上の仮想ユーザー	system_u, unconfined_u
ロール	役割を表す識別子	system_r
タイプ	アクセス制御の中核。プロセスやファイルに割り当て	httpd_t, httpd_sys_content_t
レベル	MLS/MCS環境での機密区分	s0, s0-s15:c0.c1023

この「タイプ」が最も重要で、実際のアクセス許可・拒否は主にタイプに基づいて決まります。例えば、httpdプロセスにはhttpd_tが割り当てられ、読み取れるファイルはhttpd_sys_content_tラベルの付いたものに限定されます。

ラベルは誰が決めるのか

SELinuxのラベルは、単にOSベンダーが独自に決めているわけではありません。実際には、アプリケーションの開発元（ベンダー）とディストリビューター（Red HatやFedoraなど）が協力し、双方の情報を元にSELinuxのポリシーとして提供されています。

例えばApacheの場合、Webサーバーの開発元は「httpdは/var/www/html以下のファイルを利用する」という仕様を提示します。それを受けてディストリビューターがSELinuxポリシー内にhttpd_sys_content_tというラベルを定義し、httpdプロセスに関連付けます。結果として、Apacheをインストールすると自動的にWebコンテンツに適切なラベルが付与され、正しく動作する仕組みが整います。

同様にPostgreSQLでは、ベンダー側が「データベースの格納先は/var/lib/pgsqlである」と仕様を示し、ディストリビューターがpostgresql_db_tというラベルを定義して制御ルールを組み込みます。これにより、データディレクトリが自動的に適切なラベルで保護され、不正アクセスを防げるようになります。

このように、SELinuxのラベルは「ベンダーのアプリ仕様」と「ディストリビューターのセキュリティ実装」が合わさって定義されており、管理者はその仕組みを前提に自分のシステムに合わせた調整を行うことになります。 

SELinuxの導入と基本操作

SELinuxは多くのRHEL系Linuxで標準的に導入されていますが、環境によっては無効化されていたりパッケージが不足している場合があります。

ここではSELinuxの導入状況を確認し、基本的な操作を整理していきます。

パッケージの確認と導入方法

SELinuxを利用するには関連パッケージが必要です。特にRHEL系ディストリビューションでは「policycoreutils」「selinux-policy」「selinux-policy-targeted」が揃っていることが前提です。これらが不足していると、getenforceやsetenforceが利用できず、ポリシーも適用されません。

まずはパッケージの導入状況を確認します。

dnf list installed | grep selinux

【出力例:】

container-selinux.noarch 4:2.237.0-1.el9_6 @appstream
fail2ban-selinux.noarch 1.1.0-6.el9 @epel
flatpak-selinux.noarch 1.12.9-4.el9_6 @appstream
libselinux.x86_64 3.6-3.el9 @anaconda
libselinux-utils.x86_64 3.6-3.el9 @anaconda
python3-libselinux.x86_64 3.6-3.el9 @AppStream
rpm-plugin-selinux.x86_64 4.16.1.3-37.el9 @anaconda
selinux-policy.noarch 38.1.53-5.el9_6 @anaconda
selinux-policy-targeted.noarch 38.1.53-5.el9_6 @anaconda

不足している場合は以下のコマンドで導入してください。

dnf install policycoreutils selinux-policy selinux-policy-targeted

パッケージが揃っていれば、getenforceで現在の状態を確認できます。

getenforce

【出力例:】

Enforcing

動作モードの確認と切り替え（getenforce, setenforce）

SELinuxには「Enforcing」「Permissive」「Disabled」の3つのモードがあります。現在の動作モードはgetenforceで確認できます。

getenforce

【出力例:】

Enforcing

一時的にモードを切り替える場合はsetenforceを使用します。

setenforce 0
getenforce

コマンド	モード	説明
setenforce 0	Permissive	違反を許可しつつログに記録します
setenforce 1	Enforcing	違反操作を拒否し、セキュリティポリシーを強制します

【出力例:】

Permissive

再びEnforcingへ戻すことも可能です。

setenforce 1
getenforce

【出力例:】

Enforcing

ここまでが「SELinuxが有効な環境」での通常の動作確認と切り替えです。

SELinuxが無効化（Disabled）と表示される場合

環境によってはSELinuxが無効化（Disabled）されている場合があります。その場合、同じコマンドを実行すると以下のように表示されます。

getenforce

【出力例:】

Disabled

この状態ではsetenforceを実行しても切り替えはできません。

setenforce 0

【出力例:】

setenforce: SELinux is disabled

これはカーネルブート時にSELinux自体が無効化されているためです。この場合は設定ファイルを修正し、再起動する必要があります。

vi /etc/selinux/config

【修正前】

SELINUX=disabled

【修正後（有効化する場合）】

SELINUX=enforcing

または検証用に以下の設定とすることも可能です。

SELINUX=permissive

修正後に再起動するとSELinuxが有効になり、再びgetenforceやsetenforceで状態を切り替えられるようになります。

コンテキストの確認と変更（ls -Z, chcon, restorecon）

SELinuxは「セキュリティコンテキスト」に基づいてアクセス制御を行います。

まず対象ファイルのコンテキストを確認してみましょう。

ls -Z /var/www/html/

【出力例:】

-rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 index.html

コンテキストを一時的に変更する場合はchconを使用します。

chcon -t httpd_sys_content_t /var/www/html/test.html

元に戻す場合はrestoreconを実行します。

restorecon -v /var/www/html/test.html

【出力例:】

restorecon reset /var/www/html/test.html context unconfined_u:object_r:default_t:s0->system_u:object_r:httpd_sys_content_t:s0

このように、コンテキストの正しい設定がSELinux運用の基本となります。

基本操作がセキュリティ強化に直結する理由

getenforceやsetenforceといった基本操作は、単なるモード確認や切り替えのためのコマンドではありません。これらを使うことで、システムが「いまどの防御レベルで動いているのか」を即座に把握できるという大きな利点があります。

例えば、Enforcingモードは不正なアクセスを即座に拒否しますが、その分アプリケーションの挙動を制限する場合があります。逆にPermissiveモードではアクセス自体は許可されますが、拒否されるはずの操作をログに残すため、トラブルシュートや設定検証に役立ちます。

このように、状況に応じてPermissiveとEnforcingを切り替えることで「運用の柔軟性」と「堅牢なセキュリティ」を両立できます。つまり、基本操作は単なる設定確認ではなく、システムを守りながら安定稼働させるためのセキュリティ戦略そのものなのです。

SELinuxの基本的な使い方

SELinuxを運用する上では、日常的に利用する基本コマンドの使い方を理解しておくことが重要です。アクセスが拒否された際の原因調査や、必要に応じたポリシーの管理もここで解説します。

SELinuxでは状態確認やモード切り替え、ファイルのコンテキスト確認など、複数のコマンドを利用します。以下に代表的なコマンドと用途を表にまとめます。

コマンド	用途	例
getenforce	現在のSELinuxモードを表示	Enforcing / Permissive / Disabled
setenforce	モードを一時的に切り替え	setenforce 0 → Permissive
ls -Z	ファイルやディレクトリのセキュリティコンテキストを確認	ls -Z /var/www/html/
chcon	一時的にセキュリティコンテキストを変更	chcon -t httpd_sys_content_t index.html
restorecon	既定のセキュリティコンテキストに戻す	restorecon -v index.html

ログの確認とトラブル調査（/var/log/audit/audit.log）

SELinuxによってアクセスが拒否された場合、その情報はauditログに記録されます。原因調査にはauditログの確認が欠かせません。

tail -f /var/log/audit/audit.log

【出力例:】

type=AVC msg=audit(1725605470.501:123): avc: denied { read } for pid=1234 comm="httpd" name="index.html" dev="sda1" ino=12345 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

この例では、httpdプロセスがindex.htmlにアクセスしようとしましたが、コンテキストがdefault_tのため拒否されています。アクセス権限の不整合やコンテキスト設定ミスがある場合、ログを起点に調査を行います。

ポリシーの管理（semanage, semodule）

SELinuxでは、必要に応じてポリシーを調整することで運用に適した制御を実現できます。代表的なコマンドがsemanageとsemoduleです。

例えば、httpdがTCPポート8080を利用できるようにするには以下を実行します。

semanage port -a -t http_port_t -p tcp 8080

【出力例:】

（成功時は特に出力なし）

登録内容を確認するには以下を利用します。

semanage port -l | grep http_port_t

【出力例:】

http_port_t tcp 80, 8080, 443

また、新しいモジュールを導入する場合はsemoduleを使用します。例えば追加ポリシーの読み込みは以下の通りです。

semodule -i custom_policy.pp

【出力例:】

（成功時は特に出力なし）

このように、semanageでポリシーを調整し、semoduleで追加ポリシーを管理することで、SELinuxを柔軟に運用できます。

誤設定検知とリスク回避の利点

SELinuxの基本的な使い方に含まれる ls -Zや restoreconなどのコマンドは、単にファイルのラベルを確認・修正するためのものではありません。これらは実際の運用において「誤ったコンテキストが付与されたまま放置されるリスク」を事前に検知し、攻撃者に悪用されることを防ぐ重要な役割を持っています。

例えば、Webコンテンツがdefault_tのまま公開されていると、httpdプロセスはアクセスできず、サービスはエラーとなります。一見「SELinuxが邪魔をしている」と誤解されがちですが、実際には「意図しないファイル公開」をブロックすることでシステムを守っているのです。

restoreconによるコンテキスト修正は、セキュリティ上のほころびを塞ぐ作業といえます。誤設定を正しく修正することで、不要なアクセス拒否を解消しながら、安全な状態を維持できます。つまり、基本コマンドの利用そのものが「潜在的な脆弱性の検出と修復」という意味を持つのです。 

httpd_sys_content_tラベルの役割

ApacheなどのWebサーバーは、SELinuxによってアクセス可能なファイルが厳密に制御されています。

その代表的な仕組みが「ラベル（セキュリティコンテキスト）」です。例えば、Webコンテンツ用のファイルにはhttpd_sys_content_tというラベルを付ける必要があります。

このラベルが付与されていることで、httpdプロセスはファイルを正しく読み取ることができ、Webブラウザからのアクセスに応答できます。

逆に、ラベルがdefault_tやuser_home_tなど誤った状態であれば、ファイルのパーミッションが適切に設定されていても、SELinuxがアクセスを拒否してしまいます。

つまり「httpd_sys_content_tのラベルが付いたファイルに限定」というのは、「Webサーバーはラベルで明示的に許可されたファイルしか扱えない」という強制アクセス制御の仕組みを指しています。

この制御によって、攻撃者がWebサーバーを突破したとしても、システム全体や他の領域に自由にアクセスされることを防げるのです。

SELinuxの応用と拡張

SELinuxを基本操作だけでなく応用的に活用することで、システムごとの要件に合わせたセキュリティ制御が可能になります。ここでは代表的なサービスに対するポリシー設定、永続的な設定変更、そして運用時に欠かせないログ管理と監査について解説します。

サービスごとのポリシー設定例（httpd, sshdなど）

SELinuxでは、サービスごとに定義されたポリシーを利用してアクセス制御を行います。

例えば、Apache（httpd）が80番ポート以外を利用する場合、semanageコマンドで許可する必要があります。

semanage port -a -t http_port_t -p tcp 8080 semanage port -l | grep http_port_t

【出力例:】

http_port_t tcp 80, 8080, 443

同様に、SSHのポートを変更する場合もsemanageを利用します。

semanage port -a -t ssh_port_t -p tcp 2222 semanage port -l | grep ssh_port_t

【出力例:】

ssh_port_t tcp 22, 2222

このように、サービスごとのポートをポリシーに登録することで、SELinux環境下でも正しく通信が行えます。

永続的な設定変更（/etc/selinux/config）

SELinuxのモード変更をsetenforceで行った場合は再起動すると元に戻ってしまいます。恒久的に変更したい場合は設定ファイルを修正する必要があります。

vi /etc/selinux/config

【設定例:】

# この行を変更 SELINUX=enforcing # もしくは SELINUX=permissive

変更後にシステムを再起動すると、指定したモードでSELinuxが起動します。

getenforce

【出力例:】

Enforcing

運用環境では基本的にEnforcingで利用することが推奨されますが、トラブル調査時に一時的にPermissiveにする方法も有効です。

運用時のログ管理と監査

SELinuxの動作状況はauditログに詳細が記録されます。アクセスが拒否された場合の切り分けや調査には、audit.logの確認が欠かせません。

tail -f /var/log/audit/audit.log

【出力例:】

type=AVC msg=audit(1725605470.501:123): avc: denied { read } for pid=1234 comm="httpd" name="index.html" dev="sda1" ino=12345 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

また、ausearchやsealertを利用することでログの解析を自動化できます。

ausearch -m avc -ts recent

【出力例:】

type=AVC msg=audit(1725606001.234:456): avc: denied { write } for pid=5678 comm="sshd" name="authorized_keys" dev="sda1" ino=67890 scontext=system_u:system_r:sshd_t:s0 tcontext=unconfined_u:object_r:home_ssh_t:s0 tclass=file

このように、ログ管理と監査を組み合わせることでSELinuxの動作を把握し、必要に応じたポリシー調整やトラブルシュートを行うことができます。

サービスごとの制御が持つ安全性

SELinuxの応用機能であるサービスごとのポリシー設定は、システム全体を守る上で非常に大きな意味を持ちます。例えばhttpdは、 http_port_tで定義されたポート以外にはアクセスできません。これは、攻撃者が勝手に別ポートでプロセスを動かそうとしても、SELinuxによって通信が遮断されることを意味します。

同様に、sshdの待受ポートを変更する際も、ポリシーに登録されていなければSELinuxがブロックします。これは一見「不便」と映りますが、裏を返せば「想定外の通信を自動的に防御してくれる」という強力な仕組みです。

サービス単位での制御は「許可すべき通信」と「拒否すべき通信」を明確に分離する役割を果たし、結果として不正なアクセスや設定漏れによるセキュリティホールを未然に防ぎます。単なる制約ではなく、サービスを正しく守るための安全弁として機能しているのです。 

SELinuxのトラブル対応

SELinuxは強力なセキュリティを提供する一方で、誤った設定やポリシーの影響により「アプリケーションが動かない」「アクセスできない」といったトラブルの原因になることがあります。

ここでは、よくある不具合とその解決方法、アクセス拒否の切り分け、さらに一時的な無効化と恒久的な設定の違いについて整理します。

よくある不具合の症状と解決方法

SELinuxが原因で発生する典型的な不具合として、Webサーバーやデータベースへのアクセス拒否があります。

例えば、httpdでドキュメントルートを変更した場合、正しいパーミッションを設定してもSELinuxのコンテキストが異なればアクセスできません。

ls -Z /var/www/html/

【出力例:】

-rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 index.html

コンテキストが異なる場合は、以下のように修正します。

chcon -t httpd_sys_content_t /var/www/html/index.html restorecon -Rv /var/www/html/

【出力例:】

restorecon reset /var/www/html/index.html context unconfined_u:object_r:default_t:s0 → system_u:object_r:httpd_sys_content_t:s0

これにより、正しいラベルが付与されアクセスが可能になります。

許可・拒否の切り分け手順

SELinuxによる拒否かどうかを切り分けるには、まずauditログを確認します。アクセス拒否時には「avc: denied」という記録が残ります。

tail -n 20 /var/log/audit/audit.log

【出力例:】

type=AVC msg=audit(1725605470.501:123): avc: denied { read } for pid=1234 comm="httpd" name="index.html" dev="sda1" ino=12345 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file

このような場合、対象のファイルやポートがSELinuxポリシーで許可されているかを確認します。ポート利用であれば以下のようにsemanageで確認できます。

semanage port -l | grep http_port_t

【出力例:】

http_port_t tcp 80, 443

もしサービスが別ポートを利用するなら追加登録が必要です。

semanage port -a -t http_port_t -p tcp 8080

一時的な無効化と恒久的な設定の違い

トラブル調査の際にSELinuxを一時的に無効化して挙動を確認することがあります。setenforceコマンドを使うと、再起動するまでの間だけモードを切り替えられます。

setenforce 0 getenforce

【出力例:】

Permissive

再度有効にする場合は以下です。

setenforce 1 getenforce

【出力例:】

Enforcing

一方で、恒久的に変更するには設定ファイルを修正する必要があります。（前述）

vi /etc/selinux/config

【設定例:】

SELINUX=enforcing # 有効 SELINUX=permissive # 許可ログのみ SELINUX=disabled # 無効

修正後に再起動することで、指定したモードでSELinuxが起動します。調査のための一時的な切り替えと、本番運用での恒久的な設定は明確に区別して運用することが大切です。

トラブル対応が示す安全性の裏返し

SELinuxのトラブル対応は、単なる不具合解消の作業に見えるかもしれません。しかし実際には「SELinuxが危険な操作を防いでいる」ことの証拠でもあります。例えば、アプリケーションが正常に動かないとき、audit.logを確認すると必ず「avc: denied」という拒否記録が残ります。これはSELinuxが不正または想定外のアクセスを検知し、遮断したことを意味します。

もしSELinuxを無効化していれば、そのアクセスはそのまま通ってしまい、攻撃者にとって大きな突破口となってしまいます。つまり「トラブル」として現れる現象は、裏を返せば「不正挙動が確実にブロックされている」ことの証拠なのです。

この視点を持つことで、管理者はSELinuxのトラブル対応を「障害対応」としてではなく「防御が機能している証拠」として捉えられるようになります。そのうえで、正しいポリシー設定やラベル修正を行えば、システムは安全性と安定性を兼ね備えた状態へ改善されます。 

SELinux利用時の注意点

SELinuxは強力なセキュリティを提供する一方で、運用においていくつかの注意点があります。性能面での影響や、誤った設定によるリスクを理解していないと、かえってシステム運用に支障をきたすことがあります。ここでは代表的な注意点を整理します。

性能への影響と最適化

SELinuxはアクセスごとにコンテキストを参照して制御を行うため、通常のDAC（任意アクセス制御）よりも処理コストがかかります。そのため、大量アクセスが発生するシステムでは性能への影響が懸念されます。ただし、RHEL8以降では最適化が進み、オーバーヘッドはごく僅かとなっています。

性能を維持するためには、ログの肥大化を避けることが重要です。Permissiveモードで長時間稼働すると、膨大なログが生成されディスクを圧迫します。不要なログを削除したり、ログローテーションを適切に設定することで安定運用が可能です。

ls -lh /var/log/audit/

【出力例:】

-rw-------. 1 root root 120M Mar 1 10:20 audit.log -rw-------. 1 root root 80M Feb 28 23:50 audit.log.1

このように、audit.logのサイズを定期的に確認し、必要であればlogrotateによる管理を徹底することが推奨されます。

セキュリティリスクと誤設定の落とし穴

SELinuxを無効化したまま運用すると、本来ブロックされるべき不正アクセスも許可されるため、セキュリティリスクが高まります。特に外部公開サーバーでは、SELinuxが最後の防御壁となるため無効化は避けるべきです。

一方で、有効化していても誤ったコンテキスト設定により、意図せずアクセス拒否が発生するケースもあります。例えばWebコンテンツにdefault_tが付与された場合、正しいパーミッションを設定してもhttpdがアクセスできません。

ls -Z /var/www/html/index.html

【出力例:】

-rw-r--r--. root root unconfined_u:object_r:default_t:s0 index.html

この場合はrestoreconで修正します。

restorecon -v /var/www/html/index.html

【出力例:】

restorecon reset /var/www/html/index.html context unconfined_u:object_r:default_t:s0 → system_u:object_r:httpd_sys_content_t:s0

このように、SELinuxは「無効化のリスク」と「誤設定のリスク」の両方を持っています。適切に理解し、正しい設定を行うことで強固なセキュリティと安定した運用を両立できます。

Disabledにすることのリスク

SELinuxをDisabledに設定すると、確かにアプリケーションは制約なく動作するため、導入直後のトラブルは一時的に解消されます。しかしその代償は極めて大きく、システム全体が無防備な状態になります。

例えば、Apacheが侵入を受けた場合を考えてみましょう。SELinuxが有効であればhttpdプロセスのアクセスはhttpd_sys_content_tに限定されますが、Disabledであればシステム全体のファイルや他のサービスにまでアクセスが可能となり、攻撃者は自由に横展開できます。これは単なるサービス停止ではなく、システムの完全な乗っ取りにつながる重大なリスクです。

また、PCI DSSやISMSなどのセキュリティ基準では、SELinuxの無効化は監査不適合とされるケースが多く、業務システムでDisabledを選択することは事実上許されません。便利さを優先して無効化することは、「防御の最後の砦」を自ら放棄する行為と同義です。

したがって、運用上の利便性だけを理由にSELinuxをDisabledへ設定するのは極めて危険です。正しいポリシー設定やPermissiveモードでの検証を活用しながら、有効化して運用することこそが安全なシステム維持につながります。 

まとめ

ここまでSELinuxの仕組みから基本操作、応用的な利用方法、そしてトラブル対応や運用上の注意点について解説してきました。かつては運用現場で「まず無効化するもの」とされていたSELinuxですが、現在ではポリシーの成熟やツールの整備により、実際のシステム運用でも有効化して利用することが一般的になっています。

SELinuxを理解するうえで重要なのは、単に有効・無効を切り替えることではなく、ログを読み解き、コンテキストやポリシーを適切に調整できるスキルです。これにより、不要な拒否を回避しつつ、不正なアクセスをしっかり防御することが可能になります。

また、性能への影響や誤設定による落とし穴を理解し、適切に管理すれば、SELinuxはシステムを守る大きな力となります。今後はPermissiveとEnforcingを状況に応じて使い分けつつ、安易にDisabledへ設定しないことが安全なシステム運用の第一歩といえるでしょう。