SELinux

とあるきっかけで参加させて頂いた勉強会+オフ会で、SELinuxの方とお話する機会に恵まれた。私なんぞが言うまでもないけれども、これからのOSの方向性はこれでキマリだな!と感じた。すぐにでも使い始めたい魅力に溢れている。


ネックは、誰もが思うことだろうが設定ファイルの複雑さだろうか。マクロ展開後の行数だと30万行近くあるとか。この件に関して、ソフト屋という立場から感じたことを書いてみようと思う。

SELinuxの設定(ポリシー)を書き上げる行為を、ソフトウェアの開発を行うのと同じようにして出来ないでしょうか?

私はソフトウェア技術者なので、ある程度以上複雑な設定ファイルを見ると、「ああ、プログラミングだな」と思ってしまう。で、自分の仕事では、「数十キロステップ以上の使い捨てではないコード」を書くときは、

  1. 要求仕様書を書き (出力: 自然言語)
  2. それをもとに分析を行い (出力: UML)
  3. それをもとに設計を行い (出力: UML)
  4. それをもとに実装をする (出力: ソースコード)

を行うのがいつもの流れであるから、「現状のSELinux*1には、設定ファイル群(=4に相当)しかありません」というお話を伺うと多少の違和感を覚えてしまう。


折角のSecurityを大幅強化したLinuxなのだから、

  • 「○○という資産に対して△△という脅威がある。○○を△△から守るためにXXをしたい」などという要求の一覧を作成しておくと
  • 要求の一覧を元に、設定方法の設計を行うための、UMLに相当するような標準記法が確立されており
  • その標準記法から設定ファイルを生成できる

という流れで開発されていて、上で示したような中間生成物(1.〜3.)がユーザに提供されていればもっと良いのになと思う*2。FC2の開発者の皆さんは、必ず頭の中で要求→設計→実装という作業を行っている筈で、それが脳内に留まっていて紙にアウトプットされていないのは非常に惜しいと思う。


ソフトウェアの世界では、要求仕様がないと一般に、

  • 作るべきものを把握しないまま製品をつくりはじめる
  • 頂上がどこだかわからないまま山を登り始める
  • 地図をもたないまま砂漠を歩き続ける

ことになってしまうものだ。要求仕様がなければ、きちんとしたテスト計画ももちろん立てられないし、要求(=セキュリティポリシ)が実装(=設定ファイル)として本当に実現されたかのトレースも困難になる。


設計書がないと、たとえ一発目の製品はリリースされたとしても、次期製品を作る段になって

  • 影響範囲が読めないために機能の追加・削除がスムーズに行えない

となることが多い。


FedoraCore2の場合、要求仕様書に相当するものがないので、さほどスキルのない一般的なユーザは、SELinuxが一体何を保護してくれているのか正確に理解することができないのではないかな、と思う。「なんとなく全般的に安全なんです」という説明だけでは、設定の煩雑さに見合わないと敬遠してしまうユーザもいるかもしれない。


また、ディストリビューションを入手して手元のマシンにインストールした段階をソフトウェアでいう「一発目の製品リリース」、自分たちのニーズに合わせてSELinuxの設定をカスタマイズする段階を「次期製品の作成」と考えることができるはずだが、現状のFC2では、ソフトウェア開発での例から推測するに、一般的なユーザには設定の追加・変更の影響範囲を読むことが困難で、不十分な設定のまま運用してしまったり、カスタマイズ作業自体を諦めてしまったりする結果になるのではなかろうかと思う。


デフォルトの設定ファイルを開発するのはFedoraの中の人で、それを修正するのはユーザなのだ。大規模なプログラムをまったく別の人間が修正するのである。別の人間が作業を行うのだから、"バザールモデルあるいはXPでドキュメントが重視されない"といった話をそのまま適用するのは避けるべきだと考える。


まとまりのない文章のまとめ:

SELinuxは非常に強力なセキュリティ機構を提供してくれる。現状でも、ある程度以上のスキルをもつユーザであれば使いこなすことができるだろう。


現在いくつか開発が行われている、「設定ファイルをGUIを使って閲覧・編集できるツール」は間違いなく必要。あったほうが良い。しかし、他にも必要なものはある筈。

私は、それは

あたりではないかと思う。

注: わたくし、FC2をインストールしてから非常に日が浅いです。SELinuxを実際に使ってみて、誤っているところは書き直していくつもりです。


(2004/6/27追記)

*1:..おっと、SELinuxというか厳密にはFedoraCore2の話ですね

*2:う〜ん、どうにか設定の設計をUMLで書けないものかなぁ。できれば標準記法だけでなく、分析手法についてもチュートリアルレベルでいいので標準的なものがあると有難い