前回までに、SELinuxの主な機能として「TE(Type Enforcement)」を紹介しました。TEでは、プロセスに「ドメイン」を、ファイルに「タイプ」を付与します。セキュリティポリシーには、「ドメインがどんなタイプにどんなアクセスができるのか?」というルールが記載されています。このルールに記載されていないアクセスはすべて拒否されます。これにより、プロセスに最小限の権限を割り当てられるというものでした。
コンテナ環境で効果を実感する
これまで、ドメインとタイプを確認し(psとlsのZオプション)、TEが動作していることは確認できましたが、これだけではSELinuxの効果の実感に欠けるかもしれません。もう少し効果が分かる例としてSELinux上でのコンテナの動作を確認してみます。
準備としてCent OS 7に、代表的なコンテナ基盤であるDockerをインストールし、起動します。
# yum install docker
# systemctl start docker.service
yumコマンドではDockerと一緒に関連するSELinuxのポリシー(container-selinuxパッケージ)もインストールされます。
次にCent OS用のコンテナイメージをダウンロードします。
# docker pull centos:latest
SELinuxの有無による挙動の違いを確認
SELinuxの有無でどのような違いがあるのかを確認してみます。最も分かりやすい例としてカーネルのログ閲覧の振る舞いが異なるところがあります。
図1は、SELinuxが無効な場合の動作です。(1)前回使ったsetenforceコマンドにてpermissiveモードにして、SELinuxを無効にします。(2)ターミナルをもう一つ開き、test1という名前でコンテナを起動します。(3)と(4)では、dmesgコマンドにて、カーネルのログを閲覧していますが、カーネルのログが見えてしまっています。コンテナは、ホストとカーネルを共有していますので、コンテナから、ホストの情報を閲覧できてしまっていることになります。
図2では、SELinuxが有効な状態で試しています。(1)でSELinuxをenforcingモードにして有効に戻しています(ここでホストのターミナルで操作する必要があることに気を付けてください)。(2)で再びコンテナ側のシェルでカーネルのログを閲覧していますが、今度は閲覧が拒否されます。これはSELinuxを有効にしたことで拒否されているためで、SELinuxがコンテナからホストのリソースへのアクセスを制限していることが分かります。