概要
Amazon Linux 2027でEnforcing採用されるSELinuxを、最小の項目を覚えて使いこなせるようにします。
はじめに
Amazon Linux 2027のプレビュー版が2026年9月にリリースされています。
Amazon Linux 2027について、Webで検索してみるとAL2027のブログ記事がいくつか見られます。 そのほとんどでホットトピックとして扱っている話題、それは「SELinux Enforcing」です。
Amazon LinuxのSELinuxは、Amazon Linux 2022のプレビュー版で Enforcing 採用される予定でした。 ですが、Amazon Linux 2023リリース直前に Permissive に変更しました。AWSも日和ましたね。
Amazon Linux 2027ではついに「Enforcing」で来るSELinux。 そろそろ SELinux を Disable しない人生を歩みましょう。
SELinuxを無効化する理由
Linuxユーザが SELinux を無効化するのは、主に次の3つの理由です。
- SELinux が何をしているのか分からないので怖い
- SELinuxを有効にすると、稼働させたいアプリケーションが動かなくなる
- SELinuxを有効化して動かなくなったアプリケーションを調整する方法を知らない
一言で言えば、「SELinuxの仕組みを知らないから手が出ない」です。
ならば、仕組みを1つ理解すればよいのです。 仕組みさえ理解してしまえばSELinuxのトラブルは他のミドルウェア障害と同じで、
- ログを見る
- 原因を特定する
- 設定で直す
で解決します。
この記事では、仕組みの理解、Webコンテンツが動かない状態の発生、解決方法を見て「SELinuxできそうだな」を獲得します。
SELinuxの仕組み
SELinuxの仕組みは簡単に書くと、
「従来のファイル権限(DAC)に加え、すべてのプロセスとファイルにラベル(コンテキスト)を付け、ポリシーで許可された操作だけを通すMAC(強制アクセス制御)の仕組み。」
MACにより、rootで動くプロセスでも、ポリシーにない操作は拒否されます。 脆弱性を突かれて乗っ取られても、被害をそのプロセスの許可範囲内に封じ込めることができます。
従来のファイル権限(DAC)は、各ファイルやディレクトリに設定される「-rwxr--r--」で見られるパーミッションのことです。 所有者・グループ・その他ユーザに「読み取り」「書き込み」「実行」を設定するものです。
MACとDACについては、拙著「改訂4版Linuxコマンドポケットリファレンス」にも詳しく乗っているので良かったら買ってください。

このDACと、次に説明するMACでの判定でアクセス許可を絞ることで強固にします。
MACのラベル(コンテキスト)
すべてのプロセスとファイルなどのリソースに「ラベル(コンテキスト)」が付与されています。 ラベルは user:role:type:level の4つで構成されます。
- user: SELinuxのユーザ、OSユーザと異なる(User_u, root, unconfined_uなど, だいたい system_uかunconfined_uだからあまり気にするな。)
- role: ユーザの使える権限範囲のロール (大体 object_r だから気にするな)
- type: プロセスに割り当てる「タイプ(ドメイン)」。(これ重要)
- level: MLS(Multi-level security) 対象(プロセスやファイル)機密レベル。(だいたいs0だから気にするな)
例えば以下のコマンドでDACのパーミッションとMACのラベル(コンテキスト)を確認します。
$ ls -l /var/www/html/ # よく見る ls コマンド -rw-r--r--. 1 root root 120 Sep 29 10:00 a.html -rw-r--r--. 1 root root 120 Sep 29 10:05 b.html ← 見た目は同じ $ ls -Z /var/www/html/ # -Z オプションを付けるとラベル(コンテキスト)が追加表示 system_u:object_r:httpd_sys_content_t:s0 a.html system_u:object_r:user_home_t:s0 b.html ← ラベルが違う(a)
(a)の部分、type が httpd_sys_content_t である a.html は、このラベルにアクセスできるWebサーバから読み込みができます。 typeが user_home_t な b.html は、このラベルにアクセスできないWebサーバから読み込みできません。 b.htmlは、おそらくユーザがホームディレクトリからmvしたもの。mvコマンドだとラベルを維持して移動するのでこの状況が発生します。
Amazon Linux 2023やRHELなどはディストリビューションとしてMACのラベル(コンテキスト)やポリシーが適切に用意されています。 Webサーバやデータベースなどもパッケージをdnfでrpmをインストールすれば全ファイルが適切に設定されています。
これにユーザとしてファイルを追加、移動、修正した場合にポリシー違反を作ってしまうから混乱が起きます。 ディストリビューションのポリシーに併せて対応すればSELinuxは怖くありません。
SELinuxのトラブル解決の調査方法での第一歩はこれです。
- ls -l でパーミッションを確認
- ls -Z でMACを確認
次からSELinuxを使いこなすコマンドを紹介します。
SELinuxのために覚えるコマンド
とりあえず4つだけ覚えましょう。
- sestatus SELinuxの状態表示する
- restorecon ファイルやディレクトリのSELinuxラベルを、ポリシーに定義された本来の状態に戻す
- semanage SELinuxのポリシーを再コンパイルせずに設定を管理する
- ausearch 監査ログ(/var/log/audit/audit.log)から条件に合うイベントを検索する
sestatus
sestatusは、SELinuxの現在の状態を確認するコマンドです。
$ sestatus # SELinuxの状態確認 SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing # 現状モード (1) Mode from config file: enforcing # 起動時モード (2) Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 35
(1)(2) に差異がある場合はsetenforceで誰かが一時的に変更して戻してない状態です。 一時的にSELinuxの状態を変更するsetenforceコマンドがあります。サーバ構築中やトラブルシューティングの際に setenforce でdisableにし、そのまま作業終了すると(1)と(2)で差が表示されます。
restorecon
restoreconは、ファイルやディレクトリのSELinuxラベルを、ポリシーに定義された本来の状態に戻すコマンドです。 ファイルを別の場所から移動(mv)や、誤ってラベルを変更すると、アクセスが拒否される原因になります。 -Rで再帰的に処理でき、-vで変更内容を表示します。恒久的な設定はsemanage fcontextで登録します。
$ restorecon -Rv /var/www/html # b.htmlが正しいポリシーになってないことを警告してくれます。 Relabeled /var/www/html/b.html from system_u:object_r:user_home_t:s0 to system_u:object_r:httpd_sys_content_t:s0
各ディレクトリに設定されているポリシーは「semanage fcontext -l」で確認できます。 restoreconは設定されているポリシーにそのディレクトリ配下のファイルがマッチしているかを確認・変更して正すことができます。
semanage
semanageは、SELinuxのポリシーを再コンパイルせずに設定を管理するコマンドです。 以下のように実行すると、Webコンテンツを格納するディレクトリのコンテンツを確認できます。 このディレクトリ配下(例えば /var/www/html/index.html)が読めない場合、ls -Zで確認し、ラベルが一致しているか確認し、誤ってる場合はファイルのコンテキストを変更すればよいのです。
$ sudo semanage fcontext -l | grep "/var/www" | head -n 3 /var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0 /var/www(/.*)?/logs(/.*)? all files system_u:object_r:httpd_log_t:s0 /var/www/[^/]*/cgi-bin(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0
参考までに、独自の /srv/www をWebサーバにアクセスさせたい場合は以下のようにします。
$ sudo semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" # ディレクトリポリシーを追加 $ sudo restorecon -Rv /srv/www
ausearch
ausearchは、Linux監査ログ(/var/log/audit/audit.log)から条件に合うイベントを検索するコマンドです。 audit2allowと組み合わせて許可ルールの作成にも使います。(ここでは触れません。)
SELinuxでトラブルかな、困ったなと思ったら/var/log/audit/audit.logを見ましょう。 ausearchでselinux関連ログを出力してみればよいです。
$ sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent # 上述の b.htmlのポリシーを戻してアクセスエラーが出たところを補足
----
time->Wed Sep 30 13:51:47 2026
type=AVC msg=audit(1790776307.061:445): avc: denied { read } for pid=3605 comm="httpd" name="b.html" dev="nvme0n1p1" ino=31434 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file permissive=0
該当ファイル b.html が scontextのアクセス元からtcontextのアクセス先としてDeniedされているのがわかります。 この対象ファイルをrestoreconすればよいです。
最後に
今回はSELinuxのファイル扱いについてだけ触れました。 SELinuxの仕組みと4つのコマンドだけ把握すれば、現在のSELinuxの8割ぐらいは使えるようになるはず。 (もちろん深く触ろうと思えば足りませんよ。)
機会があればTCPポートの扱い、独自タイプの作成などを取り上げます。 このブログを読んだけど、やっぱりSELinuxは使いたくないな、と言う場合はAWSフルマネージドのECSやEKS、lambdaなどを使いましょう。
【参考資料】 SELinuxが有効(enforcing)だったら被害を押さえられたセキュリティ事件
一部ですが、SELinuxが有効だった場合に被害を押さえられたであろう事件をピックアップします。 興味があれば調べてみてください。
- ShellShock(2014年, bash, CVE-2014-6271ほか) CGI経由のリモートコード実行が広く悪用されました。SELinuxは実行自体は止めませんが、Apacheの子プロセス(httpd_sys_script_t)からの外部接続やファイル読み書きなどがポリシーで拒否され、被害範囲が限定される。
- CVE-2016-9962(2016年, Docker/runc) コンテナからホスト側ファイルへのアクセスが可能になる欠陥でした。SELinuxが有効ならコンテナが侵害されても、ホストのファイルへは届かない。
- CVE-2019-5736(2019年, runc コンテナ脱出) 悪意あるコンテナがホストの runc バイナリを上書きして、ホストの root を奪えます。RHELなどの enforcingでは悪用が阻止された。
- CVE-2019-9213(2019年, カーネル mmap の NULL ポインタ参照) NULLページへのマッピングを悪用する公開エクスプロイトが、SELinuxの制限で動作しなかった。
- CVE-2021-3156(2021年, sudo "Baron Samedit") ヒープオーバーフローによる権限昇格です。SELinuxで閉じ込めたユーザーやサービスでは、悪用の影響が制限された。
沓名 亮典(執筆記事の一覧)
AS部ES課
Linuxでのサーバ構築・保守業務をしてましたがクラウド業務をしたくて2021年12月に入社したネットワークエンジニア。 趣味でマラソン、トレラン、トライアスロン、ロードバイクやってる変態。Linuxの本とかマンガとか発売中。