KH-FDPL に関するメモ-0009
KH-FDPLの特徴(5) - セキュリティ
- KH-FDPLではなんでもかんでも書き換え自由で、つまり一歩間違えればシステムは簡単にクラッシュさせられます。だからKH-FDPLはセキュリティにも気を配ります。
- (5-1) 名前空間によるセキュリティ。
- まず第一に、どの関数も渡されたオブジェクト以外にはアクセスできません。つまり引数にaとbというオブジェクトを渡されたら、aやbの中身はどれだけでもアクセスできますが、それ以外に手出しする方法はありません。もちろん新規にオブジェクトを作ることはできますので、自分が作ったオブジェクトに対してあれこれといじることはできると思いますが、でもそれはシステムをダウンさせることにはならないでしょう。
- この「渡されたオブジェクト」というのは、引数などで明示的に渡されたオブジェクトだけではなく、暗黙で渡されているオブジェクトも含みます。何が明示的に渡させるオブジェクトで、何が暗黙で渡されるオブジェクトなのかについては言語によって異なると思うので、残念ながらここで明記することはできません。
- だからルートオブジェクトとかを渡さない限り、プログラムができる破壊行為は限定されます。
- (5-2) リードオンリー。
- 関数にオブジェクトを渡すときには、リードオンリーとして渡すこともできます。当初はセキュリティ機能の単純化のためにこれをサポートしないことも検討したのですが、壊されたくないものを渡すたびにコピーを作ってそちらを渡すようにするのは明らかに処理速度面で悪そうだったので、やはり既存オブジェクトをリードオンリーのもとで渡す機能は付けることにしました。
- (5-3) CopyOnWrite。
- 似た内容のオブジェクトをたくさん作る場合を想定して、共通部分をメモリ内で共有できるCopyOnWriteな仕組みも導入予定です。これはセキュリティというよりもメモリ節約目的ですが、ついでなので紹介しました。
- (5-4) シンプルなセキュリティ。
- オブジェクトに対して可能な操作はたくさんあって、それぞれについて許すか許さないかを決めていくと、それはとても複雑になります。オブジェクトは作ってもいいのか？書き換えないけど書き足すのはいいのか？内容を変更しないでただ消すのはいいのか？オブジェクト名を変更するのはいいのか？・・・などなど、微妙な操作はいくらでも思いつきます。
- これらすべてに対してそれぞれ許可・不許可を管理していたら、KH-FDPLはあっという間に複雑化してしまいます。それは望ましいことではありません。・・・それで、そもそもセキュリティによって何がしたいのかということを考え直してみました。
- その結果、名前空間でのセキュリティとリードオンリーでのアクセスモードがあれば、あとは何とでもなりそうだと思いました。
- (5-5) バッファオーバーランは起きません。
- KH-FDPLでは、配列などで大きな添え字を指定して攻撃しようと思っても、それはできません。エラーにもならず、普通に記憶されます。その添え字を再び使用すれば、設定した値が返ってきます。
- この状況下での有効な攻撃手法は、とにかく値をたくさん詰め込んで、メモリをあふれさせることくらいしかないと思います。それについては、何か適当なメモリ消費上限リミッタがあれば、それで問題なさそうな気がします。リミッタを超えたら実行は停止されます。ユーザはリミッタを上げてから再開してもいいですし、悪意ある行為として停止させてもいいです。
- (5-6) セキュリティとデバッグ支援。
- これは以前からのKの持論ですが、セキュリティーホールはプログラマの意志に反する動作に由来するもので、つまりはバグの一種です。ということでKH-FDPLとしてはデバック支援を充実させれば、セキュリティ対策にもなっているはずだと考えます。またデバッグ支援だけではなく、そもそもバグが起きにくくなる仕様というのも目指しています。
- (3)に書いたオブジェクトの寿命管理についても、まさにバグが起こりにくくなる仕組みの一つです。
- 変数や関数の一覧を表示させることもできます。これはディレクトリに対してlsするような感じです。デバッグの助けになるかもしれません。
こめんと欄
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
