SELinux入門｜Linuxセキュリティの基本設定と運用手順
※本記事にはプロモーション（広告）を含みます。
SELinuxを初めて有効化するなら、まずgetenforceコマンドで現在の動作モードを確認し、Enforcingのまま設定変更を試すのではなくPermissiveモードで挙動を検証してから本番反映する順序を守ってください。SELinuxはアクセス制御の仕組みが通常のLinux権限と大きく異なり、いきなり本番環境でポリシーを変更するとサービス停止につながる場合があります。本記事では仕組みの基礎から具体的な設定コマンド、トラブル発生時の解析手順までを順を追って解説します。
- SELinuxの仕組みと必要性
- 導入前に確認すべき設定
- 基本設定と運用手順
- トラブルシューティングの勘所
- 運用を安定させる工夫
- よくある質問
- まとめ
SELinuxの仕組みと必要性
SELinux（Security-Enhanced Linux）は、米国家安全保障局（NSA）が開発に関わったLinuxカーネルのセキュリティモジュールです。Red Hat Enterprise LinuxやCentOS、Fedoraでは標準搭載されており、Ubuntuなど一部ディストリビューションではAppArmorが代替として採用されています。通常のLinux権限管理とは異なる仕組みで動くため、最初に構造を理解しておくと後の設定作業が格段に楽になります。
DACとMACの違い
一般的なLinuxのファイル権限（rwx）は「任意アクセス制御（DAC: Discretionary Access Control）」と呼ばれ、ファイル所有者が自分の判断でアクセス権を変更できます。一方SELinuxは「強制アクセス制御（MAC: Mandatory Access Control）」を採用し、システム全体で定義されたポリシーに従ってアクセスを制御します。ファイル所有者であっても、ポリシーで許可されていない操作はrootユーザーでもブロックされる場合があります。この二重構造により、仮にアプリケーションに脆弱性があって不正にroot権限を奪われても、被害範囲をポリシーで定めた範囲内に抑え込む効果が期待できます。
SELinuxが動作する仕組み
SELinuxはプロセスやファイルに「セキュリティコンテキスト」というラベルを付与し、そのラベル同士の組み合わせをポリシーで許可・拒否する形で動作します。コンテキストはuser:role:type:levelという4つの要素で構成され、実務上はtype(タイプ)を意識する場面がもっとも多くなります。たとえばWebサーバーのプロセスにはhttpd_tという型が、公開用ドキュメントにはhttpd_sys_content_tという型が付与され、この組み合わせが許可されているためApacheはドキュメントを読み込めます。逆に一般ユーザーのホームディレクトリに置いたファイルにはuser_home_tのような型が付与されるため、Webサーバープロセスから読み込もうとするとブロックされます。
導入前に確認すべき設定
設定変更を始める前に、現状のモードとログ出力先を把握しておく必要があります。確認を怠ったまま作業を進めると、意図しない箇所でアクセス拒否が発生した際に原因の切り分けに時間がかかります。
有効化状態の確認方法
現在のSELinuxの状態はgetenforceコマンドで確認できます。出力結果は次の3種類のいずれかになります。
| モード | 動作内容 | 主な用途 |
|---|---|---|
| Enforcing | ポリシー違反のアクセスを実際にブロックする | 本番運用環境 |
| Permissive | ポリシー違反を記録するがブロックはしない | 設定検証・移行前テスト |
| Disabled | SELinux機能そのものを無効化する | 基本的に非推奨（デバッグ目的の一時利用に限る） |
より詳細な情報を確認したい場合はsestatusコマンドを使います。ポリシーの種類（targetedかminimumかmls）や、設定ファイル上のモードと実行中のモードが一致しているかまで一覧表示されるため、初回確認時はgetenforceよりsestatusを実行する方が状況を把握しやすくなります。
モード切り替えの基礎
一時的にモードを切り替える場合はsetenforceコマンドを使用します。setenforce 0でPermissiveに、setenforce 1でEnforcingに切り替わりますが、この変更は再起動すると失われる点に注意してください。恒久的に設定を変更したい場合は/etc/selinux/configファイルのSELINUX=の行を書き換えます。設定ファイルを直接編集した場合は反映のためにOS再起動が必要になります。Disabledから再度Enforcingへ戻す際は、ファイルシステム全体のラベル再付与（リラベル）が必要になるため、/.autorelabelファイルを作成してから再起動する、あるいはfixfilesコマンドを使う手順を踏んでください。この手順を省略するとラベルの不整合によって多数のサービスが起動しなくなるおそれがあります。
基本設定と運用手順
SELinuxは一度Enforcingで安定稼働させてしまえば、日常的な管理コストはそれほど高くありません。ここでは実務でよく使う設定操作を紹介します。
ポリシーとブール値の設定
SELinuxには「ブール値」という仕組みがあり、ポリシーの一部機能をON/OFFで切り替えられます。たとえばApacheがネットワーク経由でデータベースに接続することを許可したい場合、httpd_can_network_connect_dbというブール値を有効にします。設定確認と変更は次のコマンドで行います。
- getsebool -a：全ブール値の一覧と現在の状態を表示
- setsebool httpd_can_network_connect_db on：一時的に有効化
- setsebool -P httpd_can_network_connect_db on：再起動後も設定を維持（永続化）
ここで重要なのは、-Pオプションを付けないと再起動時に設定が元に戻る点です。動作検証を終えて本番反映する段階で必ず-Pを付与してください。
コンテキストの管理
ファイルやディレクトリを新規作成・移動した場合、意図した型が自動的に付与されないことがあります。特にmvコマンドで別ディレクトリからファイルを移動した際は、移動元のコンテキストを引き継いでしまう点に注意が必要です。現在のコンテキストを確認するにはls -Zを、変更するにはchconコマンドを使います。ただしchconによる変更は一時的なものであり、システムがラベルを再付与すると元に戻ってしまいます。恒久的に型を割り当てたい場合はsemanage fcontextでルールを登録したうえで、restorecon -Rvコマンドを実行してファイルシステムに反映させる手順が基本になります。この2段階の手順を踏まないと、サーバー再起動やリラベル実行のタイミングで設定が失われる場合があります。
トラブルシューティングの勘所
SELinuxが原因で発生する障害の多くは「アクセス拒否ログの見落とし」に起因します。エラーメッセージだけを見て「SELinuxのせいだから無効化する」という判断は、システム全体の防御力を大きく下げるため避けるべき対処法です。
auditログの読み方
SELinuxが操作をブロックすると、その記録は/var/log/audit/audit.logに残ります。ログ量が多く読みにくいため、ausearchコマンドで絞り込んで確認するのが実務的です。たとえば直近のdenied（拒否）ログだけを抽出したい場合はausearch -m avc -tsを使い、時間範囲を指定して該当箇所を絞り込みます。ログにはscontext（アクセスを試みたプロセスのコンテキスト）とtcontext（アクセス先のコンテキスト）が記録されるため、この2つを比較するとどの型の組み合わせが不足しているかを特定できます。
audit2allowの使い方
拒否ログの原因が分かったら、audit2allowコマンドを使うと該当の拒否を許可するためのポリシーモジュールを自動生成できます。ausearch -m avc -ts recentの出力をパイプでaudit2allowに渡し、さらに-Mオプションでモジュール名を指定して生成したppファイルをsemodule -iで読み込む、という流れが一般的な手順です。ただしaudit2allowが生成するルールは「拒否されたアクセスを機械的に許可する」だけのものであり、セキュリティ上の意味を検証せずに適用すると、本来防ぐべき攻撃経路まで開けてしまう危険があります。生成されたルールは必ず内容を確認し、想定外に広い権限を許可していないかを確認してから適用してください。
運用を安定させる工夫
SELinuxは初期導入時の混乱が大きい一方、運用フェーズに入ってからの負荷は限定的です。長期運用を見据えるなら、変更のたびに履歴を残す仕組みを整えておくと後々の切り分けが楽になります。
監視と定期的な棚卸し
本番環境でsetenforce 0によるPermissive化を一時的に行った場合、検証が終わったら速やかにEnforcingへ戻す運用ルールをチーム内で明文化しておくべきです。放置したままのPermissiveモードは、SELinuxが実質的に機能していない状態と変わりません。またgetseboolやsemanage fcontext -lで登録済みルールの一覧を定期的に棚卸しし、不要になったブール値の有効化やコンテキスト設定を削除しておくと、設定変更の履歴が読みやすくなります。監査観点では、audit.logのローテーション設定を確認し、拒否ログが長期間保存される状態を維持しておくことも欠かせません。
SELinuxとAppArmorの位置づけ
Ubuntu環境ではAppArmorが標準採用されており、SELinuxとは設定方式が異なります。AppArmorはファイルパスベースでプロファイルを記述する方式で、SELinuxのようなラベルベースの仕組みとは思想が異なります。ディストリビューションを跨いだサーバー構築を担当する場合は、どちらの仕組みが標準採用されているかを事前にsestatusやaa-statusコマンドで確認し、混同したまま設定作業を進めないよう注意してください。
SELinuxの詳細な仕様やポリシー記述の文法はディストリビョンやカーネルバージョンによって差異があります。設定変更の前に、使用しているディストリビューションの公式ドキュメントで最新の仕様を確認してください。またセキュリティに関わる設定変更は本番環境へ適用する前に検証環境で十分にテストし、自己の責任のもとで実施する運用を徹底してください。
よくある質問
SELinuxを無効化してもよいか
基本的には推奨されません。SELinuxが原因でエラーが出た場合でも、まずはPermissiveモードで原因を切り分け、audit2allowなどで適切な例外設定を行う方法を優先してください。無効化は防御層をひとつ丸ごと失う対処法であり、緊急時の一時措置にとどめるべきです。
Permissiveモードのままでも安全か
安全とは言えません。Permissiveモードはログを記録するだけでアクセス拒否を実行しないため、実質的にSELinuxが機能していない状態と同じです。動作検証が終わった時点でEnforcingへ戻す運用にしてください。
setseboolとsemanageの違いは何か
setseboolはブール値のON/OFFを切り替えるコマンドで、semanageはコンテキストのルール登録やポリシーモジュールの管理など、より広い範囲の設定を扱うコマンドです。用途に応じて使い分ける必要があります。
ファイルを移動したらアクセスできなくなったのはなぜか
mvコマンドで別ディレクトリからファイルを移動すると、移動元のセキュリティコンテキストがそのまま引き継がれる場合があります。移動先で正しい型を割り当てるには、restoreconコマンドでコンテキストを再付与してください。
audit2allowの出力はそのまま適用してよいか
そのまま適用するのは避けてください。audit2allowは拒否ログを機械的に許可ルールへ変換するだけで、そのアクセスが本来許可すべきものかどうかは判断していません。生成されたルールの内容を確認し、必要最小限の権限のみを許可するよう調整してから適用する手順を踏んでください。
関連記事
まとめ
SELinuxはDACとは異なるMACの仕組みでLinuxシステムを保護する機能で、Enforcing・Permissive・Disabledという3つのモードを状況に応じて使い分けます。導入時はgetenforceやsestatusで現状を把握し、設定変更はPermissiveモードで検証してからEnforcingへ反映する順序を守ることが、事故を避ける基本の進め方です。ブール値の変更にはsetsebool、コンテキストの恒久設定にはsemanage fcontextとrestoreconを組み合わせ、トラブル発生時はausearchとaudit2allowでログを解析する流れを身につけておけば、SELinuxを無効化せずに運用を続けられます。仕様はディストリビューションやバージョンによって変わるため、実際の設定作業では公式ドキュメントを都度参照し、検証環境でのテストを経てから本番へ反映してください。
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
職場のIT課題、どこから手をつけるか整理してみませんか？
運営者の無料IT診断では、簡単な質問に答えるだけで社内のIT活用状況を整理し、改善の方向性のヒントをお返しします。売り込みはありません。
Googleフォームが開きます ／ 無料 ／ 中小企業のIT担当者・経営者向け
