著者：コーリー・ミニヤード、モンタビスタ・ソフトウェア
第1章：顧客事例への最初の接触
MontaVistaは、ネットワークアプライアンス用のSELinuxポリシー作成に関する顧客からの依頼を受けました。顧客は、アプライアンス上でアプリケーションを実行できる機能を追加しようとしており、アプライアンス上で実行されるコンテナと管理システムの間をあらゆる方向で可能な限り厳密に分離することを望んでいました。これらのアプリケーションはセキュリティ上重要なものであり、管理システムが侵害された場合に他のコンテナから保護される必要があり、同時に管理システムもコンテナから保護される必要がありました。
以前、別の顧客向けにSELinuxポリシーを作成した経験があったので、それほど難しくないだろうと考えました。しかし、それは間違いでした！以前のケースは、ディスクを備えたより大規模なシステムで、より一般的なサーバー構成でしたが、今回のシステムはディスクがなく、完全にRAMから動作する組み込みシステムでした。カーネルは、ルートファイルシステム用にカーネルが展開する組み込みCPIOアーカイブを使用して起動しました。
仕事に没頭する
SELinux は概念的には単純ですが、実際にゼロから実装するのは非常に複雑です。その複雑さのほとんどは、利用可能な標準ポリシーによって隠されています。まず、コンテナ用のシステムで lxc を動作させ、ターゲットで SELinux ソフトウェアを有効にし、リファレンス ポリシーを作成することから始めました。コンテナについては、豊富な経験があったため、すぐに完了しました。SELinux ソフトウェアはやや困難でした。多くのアプリケーション (busybox、lxc、PAM など) とカーネルは SELinux が有効になっており、正しくビルドできるようにするためにいくつかの作業が必要でした。特に PAM は厄介でした。PAM をコンパイルする必要があり、そうすることで SELinux をコンパイルできるようになります。しかし、PAM は SELinux が有効になっているため、SELinux のコンパイル後に再コンパイルして SELinux の機能を取得する必要があります。私たちはこの種の問題の経験があったので、それほど大変ではありませんでした。
参照ポリシーの適用はあまりうまくいきませんでした。最初に直面した大きな問題は、RAMディスク上での実行でした。お客様が使用していたRAMブロックデバイスは拡張属性をサポートしていないため、SELinuxコンテキストをファイルに追加することができず、結果としてtmpfsに切り替える必要がありました。幸いなことに、tmpfsは拡張属性をサポートしていました。
tmpfsが動作するようになった後、参照ポリシーの作成に取り掛かりました。しかし、そのポリシーは非常に大きく、お客様のシステム規模には大きすぎました。さらに、tmpfs上で動作させていたため、cpioには拡張属性を保存する手段がなく、すべてのファイルのセキュリティコンテキストを毎回復元する必要がありました。参照ポリシーをシステムに取り込んでインストールすることはできましたが、ファイルのセキュリティコンテキストの復元に40秒もかかってしまいました。これは到底許容できるものではありません。
残念ながら、ポリシーをゼロから完全に作成すると、スケジュールが大幅に遅れてしまいます。SELinuxセキュリティポリシーは、基本的な機能を動作させるだけでも考慮すべき点が非常に多く、その後もメンテナンスに追われることになります。基本部分をオープンソース化すれば良いのですが、セキュリティポリシーのメンテナンスは私たちの専門分野ではなく、非常に時間がかかるでしょう。このような試みはこれまで誰も行ったことがないと思います。しかし…
OpenWRTが登場
幸運なことに、OpenWRTグループが彼らのディストリビューション向けにSELinuxポリシーを開発していることが分かりました。基本的な部分は既に完成しており、主にアプリケーションサポートに注力している状態でした。まさに天からの贈り物でした。私たちが求めていたものに非常に近く、組み込みシステムで期待されるような機能をサポートしつつ、はるかに小型化されていました。
しかし、完璧ではなかった。それはCILという新しいポリシー言語で書かれており、SELinuxのメンテナーたちは最終的にあらゆるものにこの言語を使うことを想定していた。そして何よりも、私たちにとって馴染みのないものだった。基本的な概念は応用できたものの、使い方がかなり異なっていたのだ。さらに、CILを知っているだけでは（古いカーネルポリシー言語を知っているのと同じように）、十分ではない。ポリシーの作成者がシステムをどのように実装したかを知っていなければ、それを使用したり拡張したりすることはできない。
勉強と学習に多くの時間を費やしました。この件に関するドキュメントは少なかったので、ほとんどリバースエンジニアリングで解決しました。OpenWRTは、ほとんどのディストリビューションが/varに保存する内容を/tmpに保存していましたが、私たちが扱っていたのはより一般的なディストリビューションでした。また、OpenWRTはsquashfs上で動作するため、tmpfsが完全に機能していませんでした。しかし、これらは克服可能な問題でした。ファイルコンテキストは約1秒で復元でき、その他の問題もそれほど時間はかかりませんでした。もちろん、学習には時間がかかりましたが、それほど大変ではありませんでした。
セキュリティのための設計
ここからは、非常に詳細な説明に入ります。お客様は既にシステムについて十分に検討し、基本的なセキュリティ設計も整えていました。しかし、セキュリティポリシーの策定作業を進める中で、ソフトウェアにセキュリティ上の問題になりかねない箇所がいくつか見つかりました。そこで、ポリシーで対処するのではなく、プログラム自体を修正することにしました。
SELinux を使用するには、重要なデータのセキュリティを最大限に確保し、侵入が発生した場合にシステムを最大限に保護するために、システムのコンパートメント化について検討する必要があります。これは非常に重要です。設計の不十分なシステムは SELinux の恩恵をほとんど受けられませんが、同時に最も脆弱なシステムでもあります。
次回のブログ記事もお楽しみに！
MVSecureサービスとMVXpertサービスの詳細については、こちらをご覧ください。
Please reach out to discuss your particular scenario today.
