【エンジニア向け】百害あって一利なし。SELinuxの無効化のススメ
3月末から4月にかけて、自社のHPと当ブログのサーバー構築しなおしていたのだが、その際にSELinuxという機能でドはまりしてしまった。
今回は、SELinuxの問題とその対策についてお伝えする。
百害あって一利なし。SELinuxとは？
SELinuxとは、Linuxに組み込まれているセキュリティ対策機能の１つだ。正式には、
と言われている。
SELinuxは、
ことを目的として設計されている。
具体的には、主に２つの機能を実装している。
TE（Type Enforcement）
全てのプロセスに対して「ドメイン」と呼ばれるラベルを付加する。またリソースに対しても同じく「タイプ」と呼ばれるラベルを付与する。それら「ドメイン」「タイプ」に対して「読み込み」や「書き込み」をセキュリティポリシー（アクセス許可ルール）によって制御可能とするのがTEと呼ばれる機能だ。
RBAC（Roll Based Access Control）
「ロール」と呼ばれるいくつかのドメインを束ねたものを設定し、それをユーザに付与するのがRBACだ。
そうすることで、仮にあるユーザのパスワードが漏洩しても、被害を受けるのはそのユーザが持つ権限に対してのみであり、被害を最小限に押さえることができる。
だが、このSELinux。中々のじゃじゃ馬である。
設定を誤ったり、デフォルトの設定のまま運用してしまうと、
- サーバーOSが起動しなくなる（カーネルパニック）
- 特定のリソース（プロセスやファイルなど）が参照できなくなる
- アクセス許可制御が非常に複雑になる
といった数多くの弊害を生み出してしまうのだ。
その結果、WEBサイトが見えなくなったり、データベースサーバーが動作しなくなったりすることもある。
実際に、日本では利用実績が少ない。それどころか、サーバー構築時に、OSインストール直後にSELinuxを無効化することが常態化している。
絶対にやるなよ！SELinuxがらみの設定ミス
では、なぜここまでSELinuxが毛嫌いされるのか？
私が今回やらかしたケースを元に解説する。
SELinuxを無効化しようとしてやらかしたミス
SELinuxを無効化する際は、大抵のLinuxディストリビューションならば、/etc/selinux/configを変更することになる。
1
2 # This file controls the state of SELinux on the system.
3 # SELINUX= can take one of these three values:
4 # enforcing – SELinux security policy is enforced.
5 # permissive – SELinux prints warnings instead of enforcing.
6 # disabled – No SELinux policy is loaded.
7 SELINUX=enforcing ①
8 # SELINUXTYPE= can take one of these two values:
9 # targeted – Targeted processes are protected,
10 # mls – Multi Level Security protection.
11 SELINUXTYPE=targeted ②
先に結論をお伝えすると、①のSELINUXをdisabledに設定するのが正解だ。
ところが、私は②のSELINUXTYPEをdisabled（無効化）して再起動してしまったため、
とカーネルパニックを引き起こしてしまったのだ。
復旧方法は？
手順は、いたってシンプルだ。「SELINUX カーネルパニック」でググると、数多くのエンジニアがハマっているのがよくわかる笑
- デフォルトOS起動のカウントダウン画面で何かキーを押下
- GRUBメニューで起動OSを上下で選び、「e」キーを押下
- 「kernel」行を上下で選び、「e」キーを押下
- 末尾に「 enforcing=0」を追加（enforgincの前に空白を1つ入れる、イコールの入力は「^」キーを押せば入る）
- エンターキーで「kernel」を選んだ画面に戻る
- 「b」キーを押下し、OSを起動する。
- 起動後、/etc/selinux/configを確認・修正
AWS上のLinuxは、この復旧方法が使えない
ところが、私の場合、この手段が使えなかった。
カーネルパニックを引き起こす場合は、復旧方法はサーバーに接続されているモニター（コンソール）上で操作を行う必要がある。
ところが、AWSはモニター（コンソール）上は提供されておらず、あくまで遠隔操作のみである。
従って、上記の復旧手段が使えなかったのだ。
結論：設定ミスをせずに、可及的速やかに、確実に、SELinuxを無効化すべし
結果として、設定ミスをしてしまったEC2インスタンスをあきらめ、１からサーバーを構築せざるをえないはめになった。
とはいえ、SELinuxを無効化していなかったら、サーバー構築後に様々な弊害を生み出す可能性がある。
従って、Linuxサーバーを構築したのちは、設定ミスをせずに、可及的速やかに、確実に、SELinuxを無効化することを強く推奨する。