Java セキュリティ（その１）

萩谷 昌己 （東京大学）with the help of

戸沢 晶彦 （東京大学）

Java セキュリティの階層

• バイトコード検証系 (bytecode verifier)→ JDK1.2 ローダ制約 (loader constraint) の導入

• クラスローダ (class loader)→ JDK1.2 安全なクラスローダ (secure class loader)

• セキュリティ・マネージャ (security manager)→ JDK1.2 アクセス・コントローラ (access controller)

• RMI セキュリティ拡張 (RMI security extension)• JINI セキュリティ

Java アタックの歴史

http://java.sun.com/sfaq/chronology.html

Java セキュリティ・アーキテクチャ

• JDK1.0 砂場モデル (sandbox model)リモート・コード ( 信頼できないコード ) は、システム・リソースにアクセスできない( 砂場の中でしか遊べない ) 。

• JDK1.1 署名付きアプレット (signed applet)信頼できる署名の付いたコードは、ローカル・コードと同様に扱われる。

• JDK1.2 保護ドメイン (protection domain)保護ドメインを単位とした精密なアクセス制御

保護ドメイン (protection domain)

• コードベース ＋ 署名者名– コードベース (codebase) … URL– 署名者名 (signer name) …

複数指定可 (and が取られる )

セキュリティ・ポリシー (security policy)

• どの保護ドメインに どのような許可 (permission) を与えるか。

• ポリシー・ファイル (policy file) による簡潔な記述

grant [SignedBy "signer_names"] [, CodeBase "URL"] { permission permission_class_name [ "target_name" ] [, "action"] [, SignedBy "signer_names"]; permission …};

アクセス制御

• AccessController クラスの checkPermission メソッド

• その呼び出し方 :

FilePermission perm = new FilePermission("path/file", "read");AccessController.checkPermission(perm);

• 現在の実行コンテキストのもとで、アクセスの許可を調べる。

アクセス制御• アルゴリズム :

i = m;while (i > 0) { if (caller i's domain does not have the permission) throw AccessControlException; else if (caller i is marked as privileged) return; i = i - 1;};inheritedContext.checkPermission(permission);

• inheritedContext… 親スレッドのコンテキスト

特権 (previlege)• 実行コンテキストに特権を与える。

class A implements PrivilegedAction { Object run() { ... }}A a = new A();

Object o = AccessController.doPrivileged(a);

• 実行コンテキストに privileged のマークが付いて、 run メソッドが実行される。

• run メソッドの実行中は、 doPrivileged の呼び手のところで、 アクセスのチェックが終了する。

アクセス制御コンテキスト

• コンテキストの取得 :AccessControlContext acc = AccessController.getContext();

• コンテキストを指定した制御 :acc.checkPermission(permission);

• コンテキストを指定した特権の付与 :Object o = AccessController.doPrivileged(a, acc);

• アルゴリズム（コンテキストの指定がある場合） :i = m;while (i > 0) { if (caller i's domain does not have the permission) throw AccessControlException; else if (caller i is marked as privileged) if (a context was specified in the call to doPrivileged) context.checkPermission(permission); return; i = i - 1;};inheritedContext.checkPermission(permission);

アクセス制御

Permission クラス

• 抽象クラスabstract boolean implies(Permission permission)

– a.implies(b) は、許可 a が許可 bを 包含することを意味する。

• サブクラス :– AllPermission, BasicPermission,– FilePermission, SocketPermission,– UnresolvedPermission

FilePermission クラス• new FilePermission("myfile", "read,write");• new FilePermission("/home/gong/", "read");• new FilePermission("/tmp/mytmp", "read,delete");• new FilePermission("/bin/*", "execute");• new FilePermission("*", “read”);• new FilePermission("/-", "read,execute");• new FilePermission("-", "read,execute");• new FilePermission("<<ALL FILES>>", "read");

クラスローダ

• クラス・ファイルをロードするオブジェクト

• ClassLoader クラスのサブクラスのインスタンス

• クラスの名前空間を作る働きも担っている。

クラス解消アルゴリズム(class resolution algorithm)

--- SecureClassLoader の場合

• クラスが既にロードされていないかチェック。• 現在のクラスローダに委譲関係の親があれば、

親にクラスのロードを委譲。– SecureClassLoader は親を指定して作成できる。– 親が指定されていない場合は、 primordial class load

er に委譲する。• 親が解消できなければ findClass を呼び出す。

public class RT { public static void main(String arg[]) { RR rr = new RR(); R r = rr.getR(); r.speakUp(); }}public class RR { public R getR() { return new R(); }}public class R { public void Icantspeak() { ... }}public class R { public void speakUp() { ... }}

Saraswat のバグ

RT のローダは R をロード。RT のローダは RR のロードをシステム・ローダに委譲。システム・ローダは R をロード。

class B extends A { ... }class C extends A { ... }

public class D { static boolean t = true; public D() { A a; if (t) a = new B(); else a = new C(); a.speakUp(); }}

Tozawa のバグ（その１）

バイトコード検証系は、B と C のスーパークラス（の名前）をA と計算するが、 A をロードしない。名前だけで A と A を等しいとみなす。

Package java.lang;public class A { pulic java.lang.C foo(java.lang.B x) { return x; }}

public class D { public D() { java.lang.B b = new java.lang.B(); java.lang.C c = (new java.lang.A()).foo(b); }}

Tozawa のバグ（その２）

Java2 のバイトコード検証系は、システム・クラスを検証しない。

バイトコード検証

• バイトコードに対する型推論• データフロー解析の一種• JVM のバイトコードには、

バイトコード検証が可能なように、型の情報が含まれている。

– aload– iload– dload

バイトコード検証の問題点

• サブルーチン– 帰り番地が変数に格納される。– 必ずしも直接の呼び手に帰らない。– サブルーチンによって変数の使い方が異なる。（多相

性）

• オブジェクトの初期化– 初期化されていないオブジェクトの参照を 禁止しな

ければならない。– ソース・コードでは保証されているが、 バイト

コードでは、バイトコード検証系が 保証しなければならない。

• loading constraint scheme との関連– 必ずしも loading constraint scheme との 連携がう

まくいっていない。

• システム・クラスや署名付きクラスの検証– システム・クラスや署名付きクラスは、 そ

の正しさが保証されているので、 バイトコード検証を省略したい。しかし、 安易に省略すると、問題が生じる。

バイトコード検証の問題点

バイトコード検証の定式化

• 型システムによる定式化– バイトコードに対する型体系– 各命令に対する型規則– バイトコード検証を型推論として定式化す

る。– 型安全性

型推論が成功すれば実行時の型エラーは 起こらない。