3.1.18 新しいタイプのアクセス権を作成する方法

新しくアクセス権を作成するには、次の例のような方法をお勧めします。ABC 社のアプリケーション開発者が「TV を見る」ための新しいカスタムのアクセス権を作成するとします。

最初に、抽象クラス java.security.Permission (またはそのサブクラスのひとつ) を継承する新しいクラス com.abc.Permission、および com.abc.Permission を継承する新しいクラス com.abc.TVPermission を作成します。ほかのクラスの implies メソッドが正しく実装されるように注意してください。ただし、com.abc.TVPermission は中間の com.abc.Permission がなくても、直接 java.security.Permission を継承することはできます。

public class com.abc.Permission extends java.security.Permission

public class com.abc.TVPermission extends com.abc.Permission

次に、アプリケーションパッケージにそれらの新規クラスをインクルードします。

特定のコードにこの新しいタイプのアクセス権を許可する場合、各ユーザーはポリシーファイルにエントリを追加します。(ポリシーファイルの構文の詳細についてはあとのセクションで説明。) 次に、5 チャンネルを見る (watch) アクセス権を http://www.example.com/ のコードに付与するポリシーファイルの例を示します。

grant codeBase  "http://www.example.com/" {
    permission com.abc.TVPermission "channel-5", "watch";
    }

   com.abc.TVPermission tvperm = new
        com.abc.TVPermission("channel-5", "watch");
   AccessController.checkPermission(tvperm);

「channel-1:13」や「channel-*」など、より難解な TVPermissions を許可するには、これらの擬似名のセマンティクスの扱いを知っている TVPermissionCollection オブジェクトを実装する必要があるかもしれません。

新しいコードがアクセス制御の組み込みアルゴリズムを実行するためには、AccessController クラスの checkPermission メソッドを呼び出してアクセス権チェックを起動します。ClassLoader や SecurityManager があるかどうかについては、必ずしも調べる必要はありません。ただし、インストールされているセキュリティーマネージャークラスにそのアルゴリズムを任せる場合は、SecurityManager.checkPermission メソッドを呼び出します。

3.2 java.security.CodeSource

3.3 java.security.Policy

ファイルの読み書きなど、アプレット (または SecurityManager の下で実行中のアプリケーション) がセキュリティーの対象である動作を行うためには、そのアプレット (またはアプリケーション) はその動作のためのアクセス権を与えられていることが必要です。唯一の例外として、コードは必ず、同じ CodeSouce、およびその CodeSouce のサブディレクトリからのファイルの読み取りアクセス権を自動的に持ちます。この場合は、明示的なアクセス権は必要ありません。

Policy オブジェクトのインスタンスは、複数存在できますが、「有効な」インスタンスは常に 1 つだけです。現在インストールされている Policy オブジェクトは getPolicy メソッドの呼び出しにより取得でき、(Policy のリセット権を持つコードによる) setPolicy メソッドの呼び出しによって変更できます。

Policy オブジェクトが使用するポリシー情報がどこに置かれるかは、Policy の実装によります。たとえば、ポリシーの構成は、単純な ASCII ファイル、Policy クラスの直列化バイナリファイル、データベースのどれかの形で保存できます。Policy のリファレンス実装の 1 つでは、情報を静的なポリシー構成ファイルから取得します。

3.3.1 Policy のファイル形式

ポリシー構成ファイルは、エントリのリストで構成されます。1 つの keystore エントリと、0 以上の grant エントリを持たせることができます。

「キーストア」は、非公開鍵と、対応する公開鍵を認証する X.509 証明書チェーンなどのデジタル証明書が格納されたデータベースです。キーストアの作成と管理には、keytool ユーティリティーを使います。ポリシー構成ファイルで指定されているキーストアは、そのファイルの grant エントリで指定されている署名者の公開鍵を照合するために使用されます。署名者の別名を指定している grant エントリがある場合、またはプリンシパルの別名を指定している grant エントリがある場合は、ポリシー構成ファイルには必ず keystore エントリを置きます (次を参照)。

現在、ポリシーファイルで指定できる keystore エントリは 1 つだけで、2 つ目以降の keystore エントリは無視されます。keystore エントリは、ポリシーファイルの grant エントリの外であれば、どこに指定してもかまいません。keystore エントリの構文は次のとおりです。

keystore "some_keystore_url", "keystore_type";

URL は、ポリシーファイルがある場所からの相対位置を表します。たとえば、セキュリティープロパティーファイルの中でポリシーファイルが次のように指定されているとします。

policy.url.1=http://foo.bar.example.com/blah/some.policy

keystore ".keystore";

http://foo.bar.example.com/blah/.keystore

キーストアの型は、キーストア情報の格納形式とデータ形式を定義するとともに、キーストア内の非公開鍵とキーストア自体の整合性を保護するために使われるアルゴリズムを定義します。Sun Microsystems がサポートするデフォルトのタイプは、Sun Microsystems に所有権があるキーストアタイプ名「JKS」です。

ポリシーファイルの各 grant エントリは、本質的には 1 つの CodeSource とそのアクセス権から成ります。実際には、CodeSource は 1 つの URL と証明書のセットから成りますが、ポリシーファイルのエントリの内容は URL と署名者名のリストです。システムは、指定された署名者の証明書を決定するためにキーストアを調べたあとで、対応する CodeSource を生成します。

ポリシーファイルの各 grant エントリは、次の形式のどれかです。ここで先頭の「grant」は予約語で、新しいエントリの開始を示し、括弧の中にはオプション項目が示されます。各エントリ内の先頭の「permission」も予約語で、そのエントリ内で新しいアクセス権の記述が開始されることを示します。各 grant エントリは、指定したコードソースとプリンシパルに 1 組のアクセス権を与えます。

grant [SignedBy "signer_names"] [, CodeBase "URL"]
      [, Principal [principal_class_name] "principal_name"]
      [, Principal [principal_class_name] "principal_name"] ... {
    permission permission_class_name [ "target_name" ] 
               [, "action"] [, SignedBy "signer_names"];
    permission ...
};

動作のフィールドは、省略可能なオプションフィールドで、アクセス権クラスが動作を必要としない場合には省略できます。このフィールドを指定する場合は、必ずターゲットフィールドの直後に置きます。

CodeBase URL の正確な意味は、最後の文字に依存します。末尾が「/」の CodeBase は、指定されたディレクトリ内のすべてのクラスファイル (JAR ファイルを除く) を示します。末尾が「/*」の CodeBase は、そのディレクトリ内にあるすべてのファイル (クラスファイルと JAR ファイルの両方) を示します。末尾が「/-」の CodeBase は、指定されたディレクトリとその下の全サブディレクトリ内のすべてのファイル (クラスファイルと JAR ファイルの両方) を示します。

CodeBase フィールド (URL) は、省略可能なオプションフィールドで、省略した場合は「任意のコードベース」が指定されます。

最初の署名者名フィールドは、署名者に関連付けられている 1 組の公開鍵 (キーストアの証明書内にある) に、別のメカニズムを通じてマッピングされた文字列の別名です。これらの鍵は、ある署名付きのクラスが本当にこれらの署名者によって署名されたかどうかを確認するために使用されます。

この署名者フィールドは、複数の署名者の名前をコンマ区切りの文字列で指定できます。たとえば、「Adam,Eve,Charles」は、Adam と Eve と Charles によって署名されることを意味します (各者の関係は OR ではなく AND)。

このフィールドは省略可能なオプションフィールドで、省略した場合は「任意の署名者」、つまり「コードが署名付きかどうかは不問」の指定になります。

Permission エントリ内にある 2 つ目の署名者フィールドは、keystore エントリの別名を表します。この keystore エントリには、そのアクセス権クラスを実装しているバイトコードへの署名に使用される非公開鍵に対応する公開鍵が含まれます。このアクセス権エントリが有効なのは (つまりこのエントリに基づいてアクセス制御権が与えられるのは)、バイトコードの実装が別名によって正しく署名されていることが確認された場合だけです。

プリンシパルの値は class_name と principal_name のペアを指定します。このペアは、実行中のスレッドのプリンシパルセット内にある必要があります。プリンシパルセットは、Subject によって実行するコードに関連付けられます。プリンシパルフィールドは省略可能です。省略した場合は、「任意のプリンシパル」という意味になります。

キーストアの別名の置き換えに関するメモ:

プリンシパル class_name/principal_name のペアが単一引用符で囲まれた文字列として指定される場合は、キーストアの別名として扱われます。キーストアは別名を経由して X509 証明書を調査し、問い合わせます。キーストアがある場合は、principal_class は自動的に javax.security.auth.x500.X500Principal として扱われ、principal_name は証明書で名前を識別されたサブジェクトとして自動的に扱われます。X509 証明書のマッピングが見つからない場合は、grant エントリはすべて無視されます。

CodeBase フィールド、SignedBy フィールド、および Principal フィールドの順序は任意です。

Policy ファイル形式の、非公式の BNF 文法の例を次に示します。ここで小文字で始まる語はターミナル語です。

PolicyFile -> PolicyEntry | PolicyEntry; PolicyFile
PolicyEntry -> grant {PermissionEntry}; |
           grant SignerEntry {PermissionEntry} |
           grant CodebaseEntry {PermissionEntry} |
           grant PrincipalEntry {PermissionEntry} |
           grant SignerEntry, CodebaseEntry {PermissionEntry} |
           grant CodebaseEntry, SignerEntry {PermissionEntry} |
           grant SignerEntry, PrincipalEntry {PermissionEntry} |
           grant PrincipalEntry, SignerEntry {PermissionEntry} |
           grant CodebaseEntry, PrincipalEntry {PermissionEntry} |
           grant PrincipalEntry, CodebaseEntry {PermissionEntry} |
           grant SignerEntry, CodebaseEntry, PrincipalEntry {PermissionEntry} |
           grant CodebaseEntry, SignerEntry, PrincipalEntry {PermissionEntry} |
           grant SignerEntry, PrincipalEntry, CodebaseEntry {PermissionEntry} |
           grant CodebaseEntry, PrincipalEntry, SignerEntry {PermissionEntry} |
           grant PrincipalEntry, CodebaseEntry, SignerEntry {PermissionEntry} |
           grant PrincipalEntry, SignerEntry, CodebaseEntry {PermissionEntry} |
           keystore "url"
SignerEntry -> signedby (a comma-separated list of strings)
CodebaseEntry -> codebase (a string representation of a URL)
PrincipalEntry -> OnePrincipal | OnePrincipal, PrincipalEntry
OnePrincipal -> principal [ principal_class_name ] "principal_name" (a principal)
PermissionEntry -> OnePermission | OnePermission PermissionEntry
OnePermission -> permission permission_class_name
                 [ "target_name" ] [, "action_list"]
                 [, SignerEntry];

grant signedBy "Roland" {
    permission a.b.Foo;
};

grant {
   permission java.io.FilePermission ".tmp", "read";
};

grant signedBy "Roland,Li" {
  permission java.io.FilePermission "/tmp/*", "read";
  permission java.util.PropertyPermission "user.*";
};

grant codeBase "http://www.example.com/*", signedBy "Li" {
    permission java.io.FilePermission "/tmp/*", "read";
    permission java.io.SocketPermission "*", "connect";
};

grant signedBy "Roland,Li" {
  permission java.io.FilePermission "/tmp/*", "read";
  permission com.abc.TVPermission "channel-5", "watch", 
     signedBy "Li";
};

認証を確実なものにするために、バイトコードの最初のコピー (のハッシュ値) を保存して 2 つ目のコピーと比べる方法ではなく、デジタル署名を使用する理由は、アクセス権クラスの作者が合法的にクラスファイルを更新して新しい設計や実装を反映することがあるからです。

注: ファイルパスの文字列は、プラットフォームごとに異なる形式で指定する必要があります。これは、将来、全プラットフォームに共通するファイル記述言語ができるまでは必要です。上記の各例は、Solaris システム用の文字列で記述されています。Windows システムでは、文字列中で直接ファイルパスを指定する場合は、単一のバックスラッシュは次のように二重のバックスラッシュで表します。

grant signedBy "Roland" {
  permission java.io.FilePermission "C:\\users\\Cathy\\*", "read";
};

"C:\users\Cathy\*"

grant principal javax.security.auth.x500.X500Principal "cn=Alice" {
  permission java.io.FilePermission "/home/Alice", "read, write";
};

次の例は、codesource 情報と principal 情報を持つ grant 文を表しています。

  grant codebase "http://www.games.example.com",
        signedBy "Duke",
        principal javax.security.auth.x500.X500Principal "cn=Alice" {
    permission java.io.FilePermission "/tmp/games", "read, write";
  };

次の例は、キーストアの別名を置き換える grant 文を示しています。

  keystore "http://foo.bar.example.com/blah/.keystore";

  grant principal "alice" {
    permission java.io.FilePermission "/tmp/games", "read, write";
  };

3.3.2 ポリシーファイル内のプロパティーの展開

プロパティーの展開は、シェルにおける変数の展開に似ています。ポリシーファイルまたはセキュリティープロパティーファイルに次のような文字列がある場合、

"${some.property}"

この文字列は指定されたシステムプロパティーの値まで展開されます。次に例を示します。

permission java.io.FilePermission "${user.home}", "read";

permission java.io.FilePermission "/home/cathy", "read";

permission java.io.FilePermission "${user.home}${/}*", "read";

permission java.io.FilePermission "/home/cathy/*", "read";

permission java.io.FilePermission "C:\users\cathy\*", "read";

grant codeBase "file:/${java.home}/lib/ext/"

grant codeBase "file:/C:/j2sdk1.2/lib/ext/"

プロパティーの展開は、ポリシーファイル内で、二重引用符で囲まれた文字列が使用できる場所であればどこでも行われます。これには、署名者、コードベース、ターゲット名、動作の各フィールドがあります。

プロパティーの展開が許可されるかどうかは、セキュリティープロパティーファイルの policy.expandProperties プロパティーの値によって決まります。このプロパティーの値が true (デフォルト) の場合は、展開が許可されます。

注: 入れ子のプロパティーは使用できません。次に例を示します。

"${user.${foo}}"

注: grant エントリ、アクセス権エントリ、または keystore エントリで展開できないプロパティーがある場合、そのエントリは無視されます。たとえば、次のようにシステムプロパティー foo が定義されていない場合、

grant codeBase "${foo}" {
  permission ...;
  permission ...;
};

grant {
  permission Foo "${foo}";
  permission Bar;
};

keystore "${foo}";

注: Windows システムでは、文字列中で直接ファイルパスを指定する場合は、単一のバックスラッシュは次のように二重のバックスラッシュで表します。

"C:\\users\\cathy\\foo.bat"

"C:\users\cathy\foo.bat"

"${user.home}\\foo.bat"

"${user.home}\foo.bat"

"C:\users\cathy\foo.bat"

"${user.home}${/}foo.bat"

3.3.3 ポリシーファイルにおける一般的な展開

デフォルトのポリシーファイルの実装では、次の 2 つのプロトコルがサポートされます。

1. ${{self}}

   プロトコル self は、${{self}} 文字列全体を 1 つ以上のプリンシパルクラスとプリンシパル名のペアに置き換えることを示します。実際に実行される置き換えは、permission を含む grant 節の内容によって決まります。

   grant 節にプリンシパルの情報が含まれていない場合は、permission は無視されます。プリンシパルベースの grant 節のコンテキストでは、ターゲット名に ${{self}} を含む permission のみが有効です。たとえば、次の grant 節内の BarPermission は常に無視されます。

               grant codebase "www.foo.example.com", signedby "duke" {
                   permission BarPermission "... ${{self}} ...";
               };
           
   

   grant 節にプリンシパル情報が含まれている場合は、${{self}} がそのプリンシパル情報に置き換えられます。たとえば、次の grant 節の BarPermission 内の ${{self}} は、javax.security.auth.x500.X500Principal "cn=Duke" に置き換えられます。

               grant principal javax.security.auth.x500.X500Principal "cn=Duke" {
                   permission BarPermission "... ${{self}} ...";
               };
           
   

   grant 節内にコンマで区切られたプリンシパルのリストがある場合、${{self}} は、そのコンマで区切られたプリンシパルのリストに置き換えられます。grant 節内のプリンシパルクラスとプリンシパル名がどちらもワイルドカードになっている場合、${{self}} は、現在の AccessControlContext 内の Subject に関連付けられたすべてのプリンシパルに置き換えられます。

   次の例は、self とキーストアの別名の置き換えの両方を含む例を示しています。

               keystore "http://foo.bar.example.com/blah/.keystore";
   
               grant principal "duke" {
                   permission BarPermission "... ${{self}} ...";
               };
           
   

   上の例では、初めに "duke" が、javax.security.auth.x500.X500Principal "cn=Duke" に展開されます。ただし、キーストアの別名「duke」に関連付けられた X.509 証明書がサブジェクトの識別名「cn=Duke」を持っていることが前提となります。次に、${{self}} が、grant 節内で展開されたその同じプリンシパル情報に置き換えられます。javax.security.auth.x500.X500Principal "cn=Duke"
2. ${{alias:alias_name}}

   プロトコル alias は、java.security.KeyStore 別名の置換を示します。KeyStore エントリ に指定された KeyStore が使用されます。alias_name は、KeyStore の別名を表します。${{alias:alias_name}} は、javax.security.auth.x500.X500Principal "DN" に置き換えられます。DN は、alias_name に属する証明書のサブジェクトの識別名を表します。たとえば、

               keystore "http://foo.bar.example.com/blah/.keystore";
   
               grant codebase "www.foo.example.com" {
                   permission BarPermission "... ${{alias:duke}} ...";
               };
           
   

   上の例の別名 duke に関連付けられている X.509 証明書は、KeyStore (foo.bar.com/blah/.keystore) から取得されます。duke の証明書がサブジェクト識別名として "o=dukeOrg, cn=duke" を指定し、${{alias:duke}} が javax.security.auth.x500.X500Principal "o=dukeOrg, cn=duke" で置き換えられるものとします。

   次のエラー条件に該当する場合、アクセス権エントリは無視されます。

   • keystore エントリが指定されていない
   • alias_name が指定されていない
   • alias_name の証明書を取得できない
   • 取得される証明書が X.509 証明書ではない

3.3.4 アクセス権の割り当て

ワイルドカード「*」の使用が認められているなどの理由により、ProtectionDomain 内のコードソースがポリシー内の複数のエントリのコードソースに一致することがあります。

ポリシー内の適切なアクセス権セットを探すために、次のアルゴリズムが使用されます。

1. match the public keys, if code is signed.
2. if a key is not recognized in the policy, ignore the key
   if every key is ignored, treat the code as unsigned.
3. if the keys are matched, or no signer was specified {
       try to match all URLs in the policy for the keys
   }
4. if the keys are matched (or no signer was specified),
   and the URLs are matched (or no codebase was specified) {
       try to match all principals in the policy with
       the principals associated with the current executing thread.
5. if either key, URL, or principals are not matched, use built-in default
       permission, which is the original sandbox permission.

たとえば、ポリシー内に「http://www.example.com/-」がある場合は、その Web サイト上のすべてのコードベースはこのポリシーエントリに一致します。一致するコードベースには、「http://www.example.com/j2se/sdk/」および「http://www.example.com/people/gong/appl.jar」があります。

複数のエントリが一致する場合は、それらのエントリ内のすべてのアクセス権が与えられます。つまり、アクセス権は追加割り当てできます。たとえば、鍵 A で署名されたコードにアクセス権 X が与えられ、鍵 B で署名されたコードにはアクセス権 Y が与えられており、特定のコードベースが指定されていない場合、A と B の両方で署名されたコードにはアクセス権 X と Y の両方が与えられます。同様に、コードベースが「http://www.example.com/-」のコードにアクセス権 X が与えられ、「http://www.example.com/people/*」のコードにアクセス権 Y が与えられており、特定の署名者が指定されていない場合は、「http://www.example.com/people/applet.jar」からのアプレットには X と Y の両方のアクセス権が与えられます。

ここでの URL のマッチングは、純粋に構文上のマッチングです。たとえば、あるポリシーに URL「ftp://ftp.sun.com」を指定するエントリがあるとします。このようなエントリは、Java コードを直接 ftp からダウンロードして実行できる場合にだけ有用です。

ローカルファイルシステムの URL を指定する場合、ファイルの URL を使用できます。たとえば Solaris システムの /home/cathy/temp ディレクトリ内のファイルを指定するには、次のようにします。

"file:/home/cathy/temp/*"

"file:/c:/temp/*"

次のような、絶対パスを使用することもできます。

"/home/gong/bin/MyWonderfulJava"

3.3.5 デフォルトのシステムポリシーファイルとユーザーポリシーファイル

ポリシーファイルは、単純なテキストエディタ、または後述する PolicyTool ユーティリティーを使って作成できます。

デフォルトでは、システム全体のポリシーファイルが 1 つあり、ユーザーポリシーファイルが 1 つあります。

システムポリシーファイルは、デフォルトでは次の場所にあります。

{java.home}/lib/security/java.policy  (Solaris)
{java.home}\lib\security\java.policy  (Windows)

ユーザーポリシーファイルは、デフォルトでは次の場所にあります。

{user.home}/.java.policy  (Solaris)
{user.home}\.java.policy  (Windows)

Policy が初期化されると、まずシステムポリシーがロードされ、次に、ロードされたシステムポリシーにユーザーポリシーが追加されます。どちらのポリシーも存在しない場合は、組み込みポリシーが使われます。組み込みポリシーは、オリジナルのサンドボックス (sandbox) ポリシーと同じものです。

ポリシーファイルの場所は、セキュリティープロパティーファイルの中で指定されています。セキュリティープロパティーファイルは、次の場所にあります。

{java.home}/lib/security/java.security  (Solaris)
{java.home}\lib/security\java.security  (Windows)

policy.url.n

policy.url.n=URL

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

アルゴリズムは、policy.url.1 から処理を開始して、番号を 1 つずつ増やしながら、URL が見つからなくなるまで処理を続けます。したがって、policy.url.1 と policy.url.3 がある場合、policy.url.3 は読み込まれません。

アプリケーションを実行するときに、追加のポリシーファイルや別のポリシーファイルを指定することもできます。この場合は、-Djava.security.policy コマンド行引数を使って java.security.policy プロパティーの値を設定します。たとえば、次のように指定します。

java -Djava.security.manager -Djava.security.policy=pURL SomeApp

次のように、「==」の付いた形式を使うと、ここで指定されたポリシーファイルだけがロードされ、ほかのポリシーファイルは無視されます。

java -Djava.security.manager -Djava.security.policy==pURL SomeApp

appletviewer -J-Djava.security.policy=pURL  myApplet

3.3.6 Policy の評価のカスタマイズ

Policy のリファレンス実装は、「policy.provider」セキュリティープロパティー (セキュリティープロパティーファイル内) の値を、目的の Poliocy 実装クラスの完全修飾形の名前に設定し直すことにより変更できます。セキュリティープロパティーファイルは、次の名前のファイルです。

{java.home}/lib/security/java.security (Solaris)
{java.home}\lib\security\java.security (Windows)

policy.provider プロパティーは、ポリシークラスの名前を指します。デフォルトは次のとおりです。

policy.provider=sun.security.provider.PolicyFile

policy.provider=com.mycom.MyPolicy

3.4 java.security.GeneralSecurityException

• java.lang.SecurityException およびそのサブクラスは、実行時例外 (非チェック、未宣言) であり、Java プログラムの実行を中止させる。

• java.lang.Exception (宣言またはキャッチが必要) のサブクラスである java.security.GeneralSecurityException は、ほかのすべての状況でセキュリティーパッケージ内からスローされる。

RuntimeException のサブクラスである java.security パッケージ内に、現時点で 2 つの例外があります。下位互換性により、現時点ではこれらの例外は変更できません。将来この問題を再検討します。