前回までに、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コマンドにて、カーネルのログを閲覧していますが、カーネルのログが見えてしまっています。コンテナは、ホストとカーネルを共有していますので、コンテナから、ホストの情報を閲覧できてしまっていることになります。

図1●SELinuxが無効な場合はホストのカーネルログをコンテナーから閲覧できる
図1●SELinuxが無効な場合はホストのカーネルログをコンテナーから閲覧できる
[画像のクリックで拡大表示]

 図2では、SELinuxが有効な状態で試しています。(1)でSELinuxをenforcingモードにして有効に戻しています(ここでホストのターミナルで操作する必要があることに気を付けてください)。(2)で再びコンテナ側のシェルでカーネルのログを閲覧していますが、今度は閲覧が拒否されます。これはSELinuxを有効にしたことで拒否されているためで、SELinuxがコンテナからホストのリソースへのアクセスを制限していることが分かります。

図2●SELinuxが有効な場合はコンテナーからホストのカーネルログへのアクセスは拒否される
図2●SELinuxが有効な場合はコンテナーからホストのカーネルログへのアクセスは拒否される
[画像のクリックで拡大表示]