BLOG

結論

AWS は2026年9月3日、Amazon Linux 2027（AL2027）のパブリックプレビューを公開しました。発表文には「enables SELinux in enforcing mode as default」と書かれています。AL2023 の既定は enabled かつ permissive でした。既定値が、記録だけ取る側から、実際に止める側へ動いたということです。

プロセスやファイルに種別のラベルを貼り、どのラベルがどのラベルに触れてよいかを方針で決める仕組みを、Security-Enhanced Linux、略して SELinux と呼びます。permissive は方針に反する動作を記録だけして通し、enforcing は記録したうえで実際に拒否します。読み込まれる方針の名前は AL2023 も AL2027 も targeted で、同じです。変わったのは、違反したときに止めるかどうかだけです。

手順書の見直しで効くのは、permissive と無効化で触るファイルが違う点です。AL2027 の利用者ガイドは、permissive への変更を /etc/selinux/config で、無効化をカーネルのコマンドラインで書いています。では、設定ファイルに disabled と書いたままならどうなるのか。AWS の無効化のページは、そこを書いていません。

そこで運用担当に回ってくるのは、方針を自分で書く仕事ではないと筆者は考えます。手元の手順書・AMI・cloud-init・構成管理のコードから、SELinux に触っている行を全部洗い出す。そのうえでサーバーごとに enforcing・permissive・無効のどれを選ぶかを決め、理由まで書き直す。プレビューの期間は、製品ページに書かれています。2027年の初めまでです。動かせるのは、そこまでです。

根拠

1. 既定値の差は、sestatus の2行に出ます

AWS の利用者ガイドは、AL2027 について「SELinux is enabled and set to enforcing mode by default」と書いています。AL2023 のページは「SELinux by default is enabled and set to permissive mode」です。sestatus を叩いたときに違うのは、Current mode と Mode from config file の2行だけです。Loaded policy name はどちらも targeted、Policy MLS status もどちらも enabled で、こちらは変わりません。

この2行の読み方を外すと、対策の向きごと外れます。AL2023 で SELinux を放置していた環境は、方針が読み込まれていなかったわけではありません。読み込まれた方針に照らして違反を記録しながら、通していただけです。だから AL2027 で止まる動作は、いま動いている AL2023 のログにすでに出ている可能性があります。

数字が1つ動いているのも、ガイドの例示から読めます。Max kernel policy version が、AL2023 の33から AL2027 では35になっています。

2. 設定ファイルの disabled は、AL2027 で効くのか

permissive にするか、無効にするか。AL2027 の利用者ガイドは、この2つを別のページで別の手順として書いています。しかも触るファイルが違います。ここが分かれ目です。

permissive にする系統は2つあります。/etc/selinux/config の SELINUX の値を permissive に変えて、再起動して変更を完了させる。または起動時のユーザーデータに cloud-config で selinux: mode: permissive を渡す。後者には再起動を省く指定も併記されていますが、AWS 自身は安定性のために再起動を勧めています。

無効化の手順は、この設定ファイルを使いません。書かれているのは、カーネルのコマンドラインを使う流れです。grubby パッケージが入っているかを確かめ、grubby で selinux=0 を足して再起動し、getenforce が Disabled を返すことを確認する。同じページは、無効にすると方針が読み込まれず、拒否の記録も残らないと警告しています。SELinux の利点を全部失うからです。そのうえで、完全に無効にするより permissive で動かすほうを勧めています。

なぜ設定ファイルで無効化しない書き方になったのか。上流にいきさつがあります。Fedora は Fedora 34 で、/etc/selinux/config による実行時の無効化をサポートしないことにしました。変更提案の説明はこうです。SELINUX=disabled と書いたシステムは、/sys/fs/selinux がマウントされない状態で起動する。ユーザー空間は SELinux を無効と判断する。そのうえで提案は、無効にしたい利用者をカーネルコマンドラインの selinux=0 へ移したいと書いています。setenforce による permissive と enforcing の切り替えは影響を受けない、とも明記されています。

では、その1行が残った AMI は AL2027 でどう起動するのか。無効化のページは、そこに触れていません。答えは実機にあります。1台建てて、getenforce と sestatus を見る。手順書を直す前に、自分の目で確かめる値だと筆者は考えます。

3. enforcing で先に止まるのは、標準から外した場所です

標準でないディレクトリを使うと、新しく作ったディレクトリが誤った種別を引き継ぐことがある。Red Hat の「Using SELinux」が、ラベルの不具合がよく起きる原因として挙げている例です。例に挙がっているのは、/var/www/html/ ではなく /srv/myweb/ を使う場合です。ポートも同じで、Apache を標準でないポートで動かすときに方針を更新しないと起動に失敗すると書かれています。コマンドの選び方でも差が出ます。同じ文書は、mv でホームディレクトリからファイルを移すと user_home_t の種別が付いたままになることがあると注意しています。

この3つは、客先の環境でそろって踏みやすい組み合わせです。配置先を /data や /opt の下に決めてある設計書は珍しくありません。待ち受けポートを8080や10050にずらすのも、監視エージェントを入れる現場ではよくあります。別の場所に置いたファイルを mv で配るデプロイ手順も、同じくらいよく見ます。

最初に確かめる場所は決まっています。同じ文書は、SELinux に止められたときは /var/log/audit/audit.log を最初に見ると書いています。そして道具として次の5つを挙げています。

• 拒否の記録を引く ausearch
• 拒否の内容を読み解いて対処案を出す sealert
• 追加の方針を作る audit2allow
• ファイルの種別とポートの割り当てを管理する semanage
• 直した種別を実際のファイルに当てる restorecon

このうち audit2allow は、最後の手段として扱われています。

行動提案

4. 手順書と構成管理から、SELinux に触る行を全部出す

洗い出す先は散らばっています。次の場所は互いに独立して書かれていることが多いので、一つずつ当たることになります。

• 構築手順書の中の setenforce 0 と、/etc/selinux/config の書き換え
• Ansible や Chef などの構成管理コードの selinux モジュールとテンプレート
• 起動時のユーザーデータと cloud-init の設定
• AMI を焼くときのプロビジョニングスクリプト
• ミドルウェアの導入手順に紛れている「SELinux を切ってから入れる」の注記

見落としやすいのは最後です。ベンダーの手順書に書かれた一文は、自社の手順書をいくら直しても残り続けます。そこは自社では直せません。

5. コマンドより先に、なぜその状態なのかを書く

SELinux の取りうる状態は3つです。enabled で enforcing、enabled で permissive、そして無効。AL2027 の無効化のページには、permissive を勧める理由も書かれています。permissive で動かす費用は、無効にするより少し増えるだけです。そして permissive から enforcing へ移るほうが、いったん無効にしてから enforcing へ戻すより設定の手間がはるかに少ない。そう説明しています。

既定値のページには、ラベルの注記があります。permissive で動かすとファイルに誤ったラベルが付くことがあり、無効にするとファイルにラベルが付かない。どちらも enforcing で問題を起こしうる、という説明です。ただし、状態を enabled に変えたときは SELinux が自動でラベルを貼り直し、この問題を防ぐ。同じページは、そうも書いています。

だから手順書に書き残すのは、3行のコマンドより先に、このサーバーがどの状態で動いていて、なぜその状態を選んだのかになります。確かめた日付も添えます。プレビュー中に見た挙動は、一般提供で変わりえます。

6. プレビューの1台で、見るのは3つだけ

プレビュー用 AMI は1台でいい。発表文によれば、この AMI はマネジメントコンソールから全ての商用リージョンで使えます。x86-64 と ARM の両方があります。客先の本番を触らずに検証環境を用意できます。見るのは次の3つです。

1. enforcing のまま自分たちのミドルウェアが起動して通信できるか
2. audit.log にどの拒否が出るか
3. 標準から外しているディレクトリとポートが自分の環境にいくつあるか

3つめは、実機を建てる前に手元の設計書からでも数えられます。数えてから建てると、1台目で見る場所が決まります。

無効化の経路は、設定ファイルからカーネルのコマンドラインへ移りました。止まるのは、標準から外した場所。この2つを手元の手順書に突き合わせる作業は、プレビューのあいだなら本番を止めずに終わります。