Linuxのセキュリティ機能「SELinux」は組み込みからクラウドまで広く浸透し、今や避けては通れません。本連載では、SELinuxの役割と、IoT時代の活用法を実践的に紹介します。初回はまず、SELinuxとは一体どのような時に役立つのか見ていきます。 SELinuxを無効にしていませんか？ Linuxカーネルのセキュリティ機能であるSELinux（Security Enhanced Linux）が主要なLinuxディストリビューションに含まれるようになって久しいですが、システム構築の現場では、邪魔者として無効にされることが多くなっています。しかし、本当にSELinuxを無効にしてしまってよいのでしょうか？ SELinuxを有効にすると対策が難しい「ゼロデイ」を含む脆弱性を突かれても多くをブロックできます。図1、図2は、2016年9月にMySQL業界を騒がせた脆弱性について、公開された

今回はSELinuxが実際に何をしているのかの真相に迫るため、セキュリティポリシーを分析します。分析により、あるプロセスが攻撃された場合に、攻撃者の悪事をどこまで封じ込められるのかを事前に知ることができます。 設定を分析するためのツール 前回紹介したように、セキュリティポリシー設定は複数のファイルに格納されており、また中核となるallow文は約10万もあるため、手作業で把握することは現実的ではありません。実際には、表1にあるような三つのコマンドを駆使してセキュリティポリシーを分析します。 Cent OS 7のデフォルトでは、これらのコマンドのうちseinfoとsesearchがありません。この二つは「SETools」と呼ばれるパッケージに入っています。SEToolsとは、米Tresys Technology社によって開発された、SELinuxのセキュリティポリシーを分析するためのツールで、

図1（B）の段階の分析を例とともに紹介します。題材として取り上げるのは第4回でも紹介したコンテナです。第4回でコンテナからホストのカーネルログへのアクセスは許可されていないところは確認しましたが、ホストのファイルへのアクセスはどうなのでしょうか。今回は、コンテナがホストのどのファイルに書き込みアクセスを許可されているのか分析します。これにより、コンテナに脆弱性があり悪用された場合、ホストのどのファイルが破壊される危険性が把握できます。 ファイルへのアクセス許可分析はやや複雑で図2のような手順に従って分析していきます。

前回まででSELinuxの機能やポリシーの分析などを紹介しました。今回は、SELinuxのアクセス拒否が原因で起きる問題を、いくつかの事例を見ながら確認し、どのように設定を変更していけばよいのかを具体的に紹介します。 SELinuxが原因で起きる問題 通常、何かアプリケーションがきちんと動作しない場合には、SELinuxが問題になっているかどうかを切り分けるために、（1）「setenforce 0」でSELinuxを無効（Permissiveモード）にして、アプリケーションが動作するかを再度確認する。（2）/etc/selinux/configを修正し、「selinux=disabled」に変更してから再起動して、アプリケーションが動作するかを再度確認する、のいずれかを行います。 （1）または（2）の結果でアプリケーションが動作した場合には、SELinuxがアプリケーションの正常動作を妨げ

前回までに試したように、SELinuxによってアクセスが拒否されて初めてSELinuxが役に立っていると分かるケースが大半です。そこで、今回から、アクセス拒否が起こる前に、SELinuxの効果を知る方法を紹介していきます。 SELinuxが何をやっているのか知るためには、セキュリティポリシーがどうなっているのかを分析する必要があります。今回は、分析の前提知識として、セキュリティポリシーの構成要素を解説します。 第2回で説明したように、SELinuxの最も主要な機能はTEとMCSです。MCSについては、大ざっぱには、「ドメインはカテゴリーが一致するタイプにアクセス許可」という設定だけなので、特に設定を分析する必要はありませんし、コンテナーや仮想マシンの分離に使われているのみです。 残りのSELinuxの働きは、TEです。SELinuxを理解するには、どのようにTEがセキュリティポリシーに設定

前回はSELinuxの機能を利用したドメインを作成し、制御する方法を紹介しました。この際、ポリシーを追加し、許可の要/不要を吟味しました。今回はこのポリシーをより詳しく解析していきましょう。 前回、logstashドメインを作成してポリシーを付け加えていきました。また、ポリシーを追加していく際には本当にその許可が必要なのかを吟味する必要があることも説明しました。 前回の作業を繰り返して行った結果、以下のようなlogstash.teファイルが出来上がっていると仮定します（図1）。今回は、このファイルから生成されたポリシーを解析します。

「IoT時代の最新SELinux入門」連載も今回が最後になります。連載の最後に、SELinuxの現在の開発の状況と、今後どのような方向に開発が進んでいくのかを過去の例から考えてみましょう。 SELinuxの現状の整理に関しては、毎年のLinux Security Summit（2017年9月に北米で開催される予定です）でまとまった資料がプレゼンテーションとして紹介されます。本記事の執筆時点（2017年7月）ではまだ資料がアップデートされていませんので、昨年の資料＊1を参考にしながら、現時点での状態を見てみましょう。 SELinuxの根本であるTypeEnforcementモデルや強制アクセス制御など根幹部分は昔と全く変わっていません。それだけ、根本部分に関しては完成されたものであるといえます。現在はSELinuxのポリシーをより運用管理者が扱いやすくする方向や、SELinuxによって提供さ

前回までに、SELinuxの主な機能として「TE（Type Enforcement）」を紹介しました。TEでは、プロセスに「ドメイン」を、ファイルに「タイプ」を付与します。セキュリティポリシーには、「ドメインがどんなタイプにどんなアクセスができるのか？」というルールが記載されています。このルールに記載されていないアクセスはすべて拒否されます。これにより、プロセスに最小限の権限を割り当てられるというものでした。 コンテナ環境で効果を実感する これまで、ドメインとタイプを確認し（psとlsのZオプション）、TEが動作していることは確認できましたが、これだけではSELinuxの効果の実感に欠けるかもしれません。もう少し効果が分かる例としてSELinux上でのコンテナの動作を確認してみます。 準備としてCent OS 7に、代表的なコンテナ基盤であるDockerをインストールし、起動します。

この記事の目的 SELinux って邪魔者ですか？ 「トラブルシュートの時に邪魔だから」「トラブルの元だから」とか言う理由で /etc/selinux/config で SELINUX=disable したり setenforce 0 したりしていませんか？ SELinux は理解さえすればとても簡単です． 本番環境でファイアウォールと WAF の設定をして満足していないで SELinux を使いましょう． 対象 SELinux を初めて触る人向けです． 玄人の方は他へ．．． 本稿の範囲 本稿では SELinux を導入しておしまいです．あくまで「みんな，簡単だからね，使おうね！」と言いたいのです． 本当は SELinux の効果を示すために Exploit を仕込んだアプリケーションから root を取って不正にファイルに触るところまでやりたいのですが，これまた別の記事にします． 僕の願