「SELinuxが邪魔をするから無効にする」
インフラエンジニアなら一度は聞いたことがある言葉です。私自身、現場でそういう判断を何度も見てきました。設定が複雑で、ソフトウェアがうまく動かないことも多い。「とりあえず無効にして先に進む」という選択は、現実的な対処として長年続いてきました。
でも、その選択が通用しなくなる時代が近づいています。
SELinuxとは何か
SELinux（Security-Enhanced Linux）は、Linuxに組み込まれたアクセス制御の仕組みです。通常のLinuxの権限管理（読み取り・書き込み・実行）に加えて、「どのプロセスが、どのファイルに、どういう操作をしてよいか」を細かく定義します。
たとえばWebサーバーのプロセスが、本来アクセスする必要のないシステムファイルに触れようとした場合、SELinuxがそれを拒否します。不正アクセスや設定ミスによる被害を最小限に抑えるための仕組みです。
ただし、この細かい制御が「面倒」の原因でもありました。新しいソフトウェアをインストールしようとするとSELinuxがブロックする。ログを見てポリシーを書いて——という作業が必要になるため、「無効にした方が早い」という判断が現場に広まっていきました。
RHEL 10が打ち出した方向性
Red Hat Enterprise Linux 10（RHEL 10）では、セキュリティへの姿勢がより厳格になっています。rootアカウントのデフォルト無効化、SELinuxを前提とした設計の強化——「セキュリティを後から足すのではなく、最初から組み込む」という方向性が明確になっています。
現場で起きている矛盾
しかしここに、現実的な問題があります。
私が構築しているジョブスケジューラ（PBS Professional、Altair Grid Engine）は、SELinuxを有効にした状態ではインストールが難しいという問題があります。OSが「SELinuxを有効にして運用せよ」と言っているのに、動かすソフトウェアが「SELinuxが有効だと動けない」と言い出す。
これは決して珍しいケースではありません。長年「SELinuxは無効にするもの」という前提でソフトウェアが作られてきた結果、SELinuxへの対応が後回しにされているプロダクトが多く存在します。
この矛盾への対処は、現状3つの方向性があります。
- SELinuxのポリシーをカスタマイズする——該当ソフトウェアに必要な権限だけを例外として定義する。正攻法だが、設定と検証に時間がかかる
- permissiveモードで運用する——SELinuxを完全に無効化はせず、ブロックはしないがログに記録する状態にする。問題を把握しながら段階的に対応するための暫定策
- ソフトウェア側の対応を待つ——ベンダーがSELinux対応を進めるのを待つ。長期的には正解だが、今すぐの解決にはならない
インフラエンジニアとして今考えること
「SELinuxを無効にする」という選択は、短期的には問題を解決します。でも、その選択を積み重ねた現場が、RHEL 10以降の環境でどういう状況に直面するか——それを今から考えておく必要があります。
SELinuxのポリシーを書けるエンジニアは、今後の現場で確実に必要とされます。「無効にして先に進む」ではなく、「なぜブロックされているのかを読んで、適切に対処できる」スキルが、これからのインフラエンジニアには求められます。
21年間現場を歩いてきた経験から言えば、こういう地味なスキルの差が、数年後に大きな差になります。
