組み込みSELinuxの今後

組み込み SELinux

SELinuxネ申から、重いメールが来てた。
考えて返事をせねばならない。

組み込みSELinuxを今後どうすべきかという話を考える必要があると思う。
彼の話を見てると、我々の選択肢は２つあるっぽい

  • 1) 軽いSELinuxを作って、そこから機能を追加していく
    • これは、あえて古いSELinuxを使うのも含める
    • boolean, semanage, modular policyは最初は無し
    • とりあえず軽いSELinuxを短期間で作れるメリット
  • 2) 重い(最新の)SELinuxからスタート。で、人海戦術で、徐々に軽くしていく
    • boolean, modular policyなどはありだが、こいつを最適化していくことで徐々に軽くする。
    • 時間はかかるが、完璧なものが作れるかもしれない

本場的には「２」をやりたいっぽい。
せっかくの機能をフル活用してもらいたいに違いないし、
古いものをメンテするのは面倒だろうし。

SEEditを作るときも、こんな感じで、選択肢は２つあった。
「簡単なSELinuxを作って、そこから機能追加」
「難しいSELinuxから始まって、徐々に使い勝手を上げる」
私は、最初に一気に簡単なSELinuxを作るアプローチを取った。
しかし、本場のアプローチと逆だったため、本場リソースを活用できなかった反省がある。

本場リソース活用には、２）も考えたほうがいいのかもしれない。。。
しかし、２）を実用レベルに上げるまで、相当かかる予感。
必要なものは何だ？

  • libselinux, libsepolのダイエット
  • libsemanageのダイエット
    • busyboxの増大分とあわせて150k以下にしたい(AppArmorが+150Kなので)
  • repolicyのダイエット
    • 最小セットのrefpolicyを作る
    • AppArmor並に簡単にしたい
  • semanageの仕組み自体の大ダイエット/etc/selinux/targeted/以下が40Mも食ってるので、根本的に大ダイエット
    • polcy.21,file_contexts,モジュールの作業ファイルもろもろ含めて 100k以下にしたいな

１）も、うまいことやれればいいのだが。。。
うう、SELinuxの機能を削りまくって軽くしたい！
SELinuxの機能を分割して、必要なものを選べるようにしたい。
CONFIG_ENABLE_SEMANGE, CONFIG_ENABLE_SEPOL, CONFIG_ENABLE_BOOL
みたいなオプションで。
システムによって要求は違う気がする。

悩ましいなぁ。