|
JAVA Developer 2003年10月号より転載
●ReflectPermission
反射(リフレクション)を利用するアクセス権をコントロールします。
このクラスもBasicPermissionのサブクラスですが、ターゲットが1つしかありません。さらにアクションはありません。そのため、次の行を書くか書かないかのいずれかになります。
permission
java.lang.reflect.ReflectPermission
"suppressAccessChecks";
|
●SocketPermission
ソケットに対するアクセス権をコントロールします。ターゲットとしてはホスト名とポート番号による指定、アクションとしては「accept」「listen」「connect」「resolve」の4種類があります。カンマ区切りで複数指定できます。
acceptからconnectまでの3つは、BSDソケットの同名の機能とほぼ対応しますが、resolveはDNSの解決を指します。そのため、本質的にネットワークにアクセスする処理がなくても発生することがあります。
ターゲットには、DNSのホスト名と、必要に応じてコロン区切りでポート番号を記述できます。
ホスト名の代わりにIPアドレスを記述することも可能です。また、ドメイン名の場合は左端のレベルにアスタリスクを用いてワイルドカードとすることができます。BasicPermissionクラスのルールでは右端だったことに注意してください。
またポート番号はハイフンで区切ることにより、範囲を示すことができます。
ハイフンの片端を省略することもできます。左端を省略すると0から、右端を省略すると65535までを意味します。ポート番号にはワイルドカードが使えません。
アクションには、前述の4種類が利用できますが、listenは自ホスト以外で利用することができない点に注意してください。一般に、サーバー用途には「accept」と「listen」を、クライアント用途には「connect」を設定するのが必須となるでしょう。プログラムの内容次第で、それ以外のポリシーを追加する必要があります。
ワイルドカードが使えますが、BasicPermissionクラスのサブクラスではありません。そのためワイルドカードの適用パターンが異なっています。
このパーミッションクラスは非常によく用います。明示的にソケットやJavaMailを用いてほかのホストにアクセスするようなケースはいうまでもありませんが、データベースにJDBCでアクセスする際などは見落としやすいでしょう。データベースへの接続でソケットを使うことがあります。
・自ホストを指定するときの問題
SocketPermissionでは、自ホストを指定するときに困ることが多いと思います。とくに外部ネットワークで接続されていると、自ホストの表現方法が何通りも考えられます。
たとえば、ネットワーク上で196.168.0.1というIPアドレスを持っているマシンを考えてみてください。自ホストは、
196.168.0.1
127.0.0.1
localhost
と、最低でも3通りの表記で確実にアクセスできます。これ以外にホスト名が別途つけられている(hostsやDNSなど)ケースも当然考えられますので、非常に面倒なことになります。実装によって利用される識別方法が異なりますので、個別に対処する必要があります。
ソケットに関しては緩めに設定しておき、それ以外の部分で補うという選択を迫られるケースもあるかと思いますが、ターゲットとアクションの組み合わせで解決できる方向を探ってください。
●FilePermission
ローカルファイルシステムに対するアクセス権をコントロールします。これもSocketPermissionと同等かそれ以上に利用することが多いパーミッションです。それだけに、設定の方法も複雑になっていて柔軟です。
まず、ターゲットはファイルやディレクトリのパスを記述します。アクションには、「read」「write」「delete」「execute」の4種類が指定できます。これもカンマ区切りで複数指定できます。
・ターゲット
ターゲットを説明する前に、ポリシーファイルを保存したディレクトリとターゲットとの関係を説明しておきます。
ポリシーの中で相対パスを用いて記述した場合、ポリシーファイルを保存したディレクトリを基準とした相対パスになります。絶対パスを用いて記述した場合はもちろん、ポリシーファイルの場所とは関係なく絶対パスで評価されます。
ターゲットではワイルドカードが利用できますが、FilePermissionクラスも独自のワイルドカード展開です。
「/*」で終わるパスは、該当ディレクトリでのすべてのファイルを示します。「/-」で終わるパスは、該当ディレクトリでのすべてのファイルおよび、サブディレクトリに含まれるすべてのファイルを示します。
「/」で終わるパスは、そのディレクトリのみを指します。この場合、そのディレクトリに保存されているファイルは含まれないので注意してください。
ディレクトリの区切り記号としてjava.io.File.separatorCharの代わりに${/}という区切り記号が利用できます。これはUNIX環境とWindows環境とで表記が異なる部分を吸収するのが目的です。
とはいってもドライブレターがあるので解決できないというケースへの対策は後述します。
ターゲットとして、「<<ALL FILES>>」という超法規的な記述が可能です。これで全ディレクトリの全ファイルを表現できることになっています。すべてのルールを無視したような表記法ですが、Windowsの場合は全ドライブを表現する方法はこれだけですので、覚えておくとトラブルシューティングなどの際に利用できます。ほかのパーミッションと同じ感覚で、つい「*」だけの、
permission java.io.FilePermission
"*", "write, read";
|
などしがちです。しかし、こうするとカレントディレクトリのファイルにしか適用されませんので、ご注意ください。
●FilePermissionの設定例
/tmp/ディレクトリ以下の任意の作業ファイルを削除できる権利を付与するパーミッションは次のようになります。
permission java.io.FilePermission
"/tmp/-", "delete";
|
ただし、これでは削除しかできません。書き込みを許可したいのであればカンマ区切りでwriteアクションを追加する必要があります。
次に、ホームディレクトリが「/home/me/」であるとして、そのディレクトリにあるファイル全部を読みたいだけの場合、次のようになります。
permission java.io.FilePermission
"/home/me/*", "read";
|
この場合、ホームディレクトリ以下のサブディレクトリにあるファイルにはアクセスできない点に注意してください。
●AllPermission
これは全アクセス権を付与するためのパーミッションです。セキュリティがまったくなくなるため、これは慎重に利用する必要があります。
・目的
ここで紹介した組み込みパーミッションの多くは、ターゲットにワイルドカードが利用できます。そのため、ちょっとした記述だけでほぼその保護ドメインのセキュリティを無効化することが可能です(リスト2)。
|
リスト2 紹介したすべてのパーミッションを与える例
|
grant
{
permission java.io.FilePermission
"<<ALL FILES>>", "write, read, execute, delete";
permission java.net.SocketPermission
"*", "accept,listen,connect,resolve";
permission java.net.PropertyPermission
"*", "read, write";
permission java.lang.RuntimePermission
"*";
permission java.net.NetPermission
"*";
permission java.security.SecurityPermission
"*";
permission java.io.SerializablePermission
"*" ;
permission java.lang.reflect.ReflectPermission
"suppressAccessChecks";
};
|
それでもなおAllPermissionクラスが存在するのは、未知のパーミッションクラスに対しても有効であるためです。
読者が新規に作ったパーミッションであっても、AllPermissionクラスの威力にはかないません(権利が付与されてしまう)。
・利用法
それではどのような状況でこのクラスを使えばよいのでしょうか。
筆者がよく使うのは、デバッグ用途です。アプレットやRMIなどのダウンローダブルアプリケーションは、セキュリティによる動作ブロックなのか、コードの単純なバグなのか判断に苦しむことがよくあります。
AllPermissionにして動くのであれば、間違いなくセキュリティポリシーの設定ミスです。
関連リンク
JAVA Developer
定期購読のご案内
バックナンバー販売協力店
|
JAVA Developer 10月号
大特集
再入門 J2SE
特集2 Oracle9i Application Server
[特別企画]
・例外処理のメカニズム
・データベース移行術(2) 「Oracle→DB2編」
・Tomcatで試すJava2セキュリティ
|
|