OSECPUの基本設計思想
基本思想
- (1) ソフトウェアに脆弱性が生まれてしまうのは、人間の不注意に由来する。もし人間の注意力が無限大であれば、現在のOSでも脆弱性が生まれる余地はない。・・・と僕は仮定する。
- 現実では脆弱性はなくなっていないが、これは不注意を責めて結局は開発者やユーザに注意を要求するばかりであり、それだけでは限界に来ていることを示している。・・・と僕は仮定する。
- (2) したがってOSECPUにおける「セキュアなOS」としての取り組みは、不注意によるミスが起きることを前提とし、これをできるだけ予防したり早期に発見することを目指す。逆に言うならば単純な不注意そのものを責めない。それを予防できなかったことを責めるのである。
- (3) あるソフトウェアがあったとする。これに不適切なパラメータを与え、意図しない結果になった場合、「そんな使い方をするやつが悪い」というのが現代の一般的な考え方だと思うが、僕の場合は、なぜ悲惨な結果を引き起こすかもしれないのにundoができないのか、のように考える。不適切なパラメータであるとチェックできなかったのはなぜか？ソフトウェアはチェックできたのではないか？
- (4) (3)のソフトウェアを「ライブラリ」と読み替えてみよう。プログラムは不正な引数を渡してしまう。そのせいでライブラリはより下位のライブラリに対し不正な引数を渡してしまう。こういうことは珍しいことではない。・・・このケースに対して、一番悪いのは誰かといえば、最初に不正な引数を渡した「プログラム」ではない。間違いは起きてしまうものなのだから、それはやむをえないと考える。悪いのはライブラリである。ライブラリはその気になれば引数をチェックすることができたはずだ。そうすればすぐに「不正な引数で呼び出されました」と報告できる。そうすればどこが悪いのかも早期に発見できる。
- 下位のライブラリで引数の不正が発覚した場合、その原因がどこにあるか分からない。この場合は上位のプログラムのほうであるが、OSECPUにおいては、そもそも上位のライブラリが不正な引数を「素通り」させてしまった時点で「脆弱性」だと考える。つまり全てのライブラリは自分がおかしな引数を受け取っていないかチェックする義務があり、チェックせずに下位に渡してはいけないのである。
- これはライブラリに限らない。ユーザが使うようなツールでも同様のチェックはできるはずであり、すべきであると考えるのがOSECPUである。
- もちろん綿密なチェックには余計な処理時間がかかることは避けられない。したがって以下の指標を持つ。与えられたパラメータの規模Nに対してO(N)程度のチェックは全てすべきだというのがOSECPUである。それよりコストのかかるチェックについては、怠ったとしてもそれを脆弱性としてとがめられることはない。
- (5) 速度は落ちる。当然落ちる。しかしそれが何だというのだ。今やCPUは異様に速く、速度よりもセキュリティのほうが深刻なのではないか？そうなのであれば、私たちは本来すべきテストを怠ってきたというわけであり、遅くなるのはやむをえないのだ。私たちの注意力がその程度しかない以上は、それに見合った負担は甘んじてうけなければならない。OSECPUではそのように考えて、このコストだけを理由にチェックを怠ることを正当化はしない。
- (6) OSECPUでは権限という概念を極力廃する。私が言うところの権限による管理とは、目の前に全てが陳列されているものの、アクセスするには権限なるものが必要で、それによってシステムを守るという手法のことである。root権限といったら分かりやすいだろうか。もしくはCPUにおけるユーザモードとカーネルモードといってもよい。こういうやりかたは人間の管理能力では管理しきれないと考える。
- 結局権限モデルでは、権限を何とかして得るとか、権限のある人になりすますか、権限のある人をだましてやりたいことをやらせるという攻撃手法をとることになり、これは一定の成功を見ている。
- (7) OSECPUでは、権限ではなくて、そもそも存在を教えないという手法をとる。アプリは与えられた引数以外には何も見えず、自由にディレクトリの構成を知ることがそもそもできない。アクセスできるとかできないとか以前の問題で、どこをどう攻めるべきなのかが分からない。誰かに成りすまそうにも、誰に成りすませばいいのかが分からない。つまりユーザ一覧みたいな情報は、ユーザがわざわざ教えてやらない限りえられない。こういう設計を徹底する。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
