【セキュリティ】 Safe Java Native Interface 【プログラミング言語】

In IEEE ISSSE 2006.
http://www.cs.princeton.edu/~appel/papers/

SafeJNIの提案。アッペルさんの最近の研究。

JNIを使ったときにJavaの型安全性をバイパスできるような抜け道をidentifyした。

・Javaの世界からもらったリファレンスはJNI APIを使って操作されることを期待されている。しかしそれにしたがわず、リファレンスをいじったりたどったりすれば、想定外の領域をアクセスできる。
・JNI API関数の関数テーブルを上書きされてしまう。
・Cのコードは、Javaの世界からもらった配列の添字を超えてアクセスできる。
・Cのコードはヒープのどこでも読めるので、privateみたいなアクセス制御機構が効かない。
・JNIではmalloc/freeのような感じで明示的にメモリ管理をするので、ダングリングポインタ、多重フリー、メモリリークなどのバグが入る。
・JavaからCに来る時点で、どんなオブジェクトも単一の型に変換されるので、Javaの世界とCの世界で型が合わないことがある。
・Cの世界からJavaの世界のオブジェクトをアクセスするときには、型を意識して適切な関数を呼び出さなければならない。
・Cの関数からJavaの関数を呼び出せる。呼び出しから返った後には例外の検査などが必要。それをしないと予期しない結果になる。
・Cの世界にはJavaのセキュリティマネージャの制御が及ばない。

解決。

・CCuredをJavaハンドルポインタと読み出しオンリーポインタで拡張（？）した型システム。JNIに関連するinvariantを静的に強制。リファレンスをいじられて変なとこ触られたり、関数テーブルを上書きされることを防ぐ。

Javaハンドルポインタは、読むことも書くこともできない（JNI APIに渡される）ポインタ。

読み出しオンリーポインタは、そのポインタが指す領域に書き込みできないポインタ。Cで言う、ポインタのconstみたいなもの。

・動的検査の挿入。配列境界、アクセス制御、例外などの検査。

・安全なメモリ管理。メモリ領域に有効タグをつける。確保したらセット。フリーしたらクリア。タグがクリアされてる領域をフリーしようとしたら二重フリーと判断。

あまり奇をてらわず、スタンダードな感じ。