| 目次 | 前へ | 次へ |
4 アクセス制御メカニズムとアルゴリズム
4.1 java.security.ProtectionDomain
ProtectionDomain クラスは、ドメインの特性をカプセル化します。ドメインは、指定されたプリンシパルのセットのアクセス権が実行されているとき、アクセス権を与えられているインスタンスのあるクラスのセットを囲みます。ProtectionDomain は、CodeSource、ClassLoader、プリンシパルの配列、およびアクセス権のコレクションで構成されています。CodeSource は、このドメインのすべてのクラスに対するコードベース (java.net.URL)、このドメインのすべてのコードに署名された秘密鍵に対応する公開鍵の証明書のセット (java.security.cert.Certificate タイプ) をカプセル化します。プリンシパルは、コードの実行対象のユーザーを表します。
ProtectionDomain の構築時に渡されるアクセス権は、適用されているポリシーにかかわらず、ドメインにバインドされているアクセス権の静的なセットを表します。そのあと、セキュリティーチェック時に ProtectionDomain によって、現在のポリシーへの問い合わせが行われ、ドメインに付与されている動的なアクセス権が取得されます。
異なる CodeSource からのクラス、または異なるプリンシパルに実行されるクラスは、別個のドメインに属しています。
現在 Java 2 SDK の一部として提供されているコードは、すべてシステムコードとみなされ、ただ 1 つのシステムドメイン内で動作します。アプレットまたはアプリケーションは、それぞれのポリシーによって決められるドメイン内で動作します。
システムドメイン以外のドメイン内のオブジェクトが、システムドメイン以外の別のドメイン内のオブジェクトを自動的に検出できないようにすることは可能です。この区分けは、クラスを注意深く解決し、注意深くローディングすることにより行います。たとえば、ドメインごとに異なるクラスローダーを使用するなどの方法です。ただし、この方法では SecureClassLoader (またはそのサブクラス) が異なるドメインからクラスをロードできるので、これらのクラスが同じ名前空間に共存することが許されます (クラスローダーによる区分けの場合と同様)。
4.2 java.security.AccessController
AccessController クラスは、次の 3 つの目的に使用されます。それぞれの目的については、このあとのセクションで詳しく説明します。- 現在有効なセキュリティーポリシーに基づいて、重要なシステムリソースへのアクセスが許可されるか、拒否されるかを決定する
- コードを「特権」が与えられたものとしてマークし、以降のアクセスの決定に影響を与える
- アクセス制御が保存したコンテキストに関して用意される別のコンテキストから決定できるように、現在の呼び出し側コンテキストの「スナップショット」を取得する。
たとえば、アクセス制御の呼び出しには通常、次のようなコードを使用していました (JDK の旧バージョンより)。
ClassLoader loader = this.getClass().getClassLoader();
if (loader != null) {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead("path/file");
}
}
新しいアーキテクチャーでは、呼び出し元のクラスに関連するクラスローダーの有無にかかわらず、チェックを呼び出すのが一般的な方法です。コードは、次のような簡潔なものになります。
FilePermission perm = new FilePermission("path/file", "read");
AccessController.checkPermission(perm);
AccessController の checkPermission メソッドは、現在の実行コンテキストを調べて、要求されたアクセスが許可されているかどうかを正しく判断します。アクセスが許可されている場合は、ただちに復帰します。アクセスが許可されていない場合は、AccessControlException (java.lang.SecurityException のサブクラス) 例外がスローされます。
ブラウザによっては、次のようなケースがあるので注意が必要です。従来のブラウザの中には、インストールされている SecurityManager が異なるセキュリティー状態を示すものがあり、その結果、異なる動作が発生する可能性があります。旧バージョンとの互換性のため、SecurityManager の checkPermission メソッドを使用できます。
SecurityManager security = System.getSecurityManager();
if (security != null) {
FilePermission perm = new FilePermission("path/file", "read");
security.checkPermission(perm);
}
現状では、SecurityManager のこの使用法を変更しませんが、将来、Java 2 SDK に適切なアクセス制御アルゴリズムが組み込まれたときには、以後のアプリケーションのプログラミングには新しい技法を使うことをお勧めします。
SecurityManager の checkPermission メソッドは、デフォルトでは実際に AccessController の checkPermission メソッドを呼び出します。SecurityManager の実装にはそれぞれ独自の管理手法が実装されており、アクセスが許可されるかどうかの判断にさらに制限が追加されている可能性もあります。
4.2.1 アクセス権チェックのアルゴリズム
次の図のように、複数の呼び出し元のチェーンを持つ計算のスレッドで、アクセス制御のチェックを行うとします (保護ドメインの境界を越える、複数メソッドの呼び出しと仮定)。
AccessController の checkPermission メソッドがいちばん新しい呼び出し元 (File クラスのメソッドなど) によって呼び出されたとき、要求されたアクセスが許可されているかどうかを判断する基本のアルゴリズムは次のとおりです。
- 「消極的評価」を行う実装では、アクセス権のチェックが要求されたときにスレッドの状態 (現在の状態を反映し、それには現在のスレッドのスタックまたはそれに相当するものが含まれる) が調べられ、要求された特定のアクセスを許可するかどうかが決定される。
したがって、アクセス権のチェックのアルゴリズムは、現在は「消極的評価」の方法で実装されています。現在のスレッドが呼び出し元 1 から数字の昇順で m 個の呼び出し元をトラバースし、呼び出し元 m が checkPermission メソッドを呼び出すとします。基本アルゴリズム checkPermission は、アクセスが許可されているかどうかを判断するために次のコードを使用します (詳細についてはあとのセクションを参照)。
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;
};
4.2.2 特権の扱い
AccessController クラスの新しい static メソッドにより、クラスインスタンス内のコードは AccessController にそのコードの本体が「特権付きである」ことを通知できます。特権付きの場合、そのコードの本体は、アクセスの要求を引き起こしたコードが何であるかにはかかわらず、利用可能なリソースへのアクセスを要求する責任だけを負います。つまり、ある呼び出し元が doPrivileged メソッドを呼び出すと、その呼び出し元には「特権付き」のマークが付けられます。アクセス制御を決定する場合、checkPermission メソッドは、コンテキスト引数のない doPrivileged の呼び出しによって「特権付き」のマークが付けられた呼び出し側に届いたときに、チェックを中止します (コンテキスト引数については次のセクションを参照)。その呼び出し元のドメインが指定されたアクセス権を持っている場合は、checkPermission はそれ以上のチェックを行わずに正常復帰し、要求されたアクセスが許可されていることを示します。そのドメインが指定されたアクセス権を持たない場合は、通常は例外が発行されます。
「特権付き」ブロックからの戻り値が必要ない場合は、次のようにします。
somemethod() {
...normal code here...
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// privileged code goes here, for example:
System.loadLibrary("awt");
return null; // nothing to return
}
});
...normal code here...
}
PrivilegedAction は、Object を返す run という単一のメソッドを持つインタフェースです。上の例は、そのインタフェースを実装する匿名の内部クラス実装の作成を示しており、run メソッドの固定実装が提供されています。doPrivileged への呼び出し時に、PrivilegedAction の実装のインスタンスが渡されます。doPrivileged メソッドは、特権を有効にしたあとで、PrivilegedAction の実装から run メソッドを呼び出し、run メソッドの戻り値を doPrivileged の戻り値として返します。上の例では戻り値は無視されています。
内部クラスの詳細については、「ネストされたクラス」および「内部クラスの例」を参照してください。
somemethod() {
...normal code here...
String user = (String) AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
return System.getProperty("user.name");
}
}
);
...normal code here...
}
run メソッド内の動作で「チェック終了」例外 (メソッドの throws 節の中に記述される) をスローする場合は、PrivilegedAction インタフェースではなく PrivilegedExceptionAction インタフェースを使う必要があります。
somemethod() throws FileNotFoundException {
...normal code here...
try {
FileInputStream fis = (FileInputStream)
AccessController.doPrivileged(
new PrivilegedExceptionAction() {
public Object run() throws FileNotFoundException {
return new FileInputStream("someFile");
}
}
);
} catch (PrivilegedActionException e) {
// e.getException() should be an instance of
// FileNotFoundException,
// as only "checked" exceptions will be "wrapped" in a
// <code>PrivilegedActionException</code>.
throw (FileNotFoundException) e.getException();
}
...normal code here...
}
「特権付き」にはいくつか重要な点があります。まず、この概念は単一スレッドの内部でだけ存在します。特権付きのコードが終了すると、その特権は確実に消去または失効します。
次に、この例では、run メソッド内のコード本体は特権付きです。しかし、このコードが特権を持たない信頼性の低いコードを呼び出すと、呼び出されたコードは結果的にすべての特権を与えられることになります。アクセス権は、特権付きのコードがそのアクセス権を持つ場合にだけ与えられ、checkPermission の呼び出しに至る呼び出しチェーンのこれ以降の呼び出し元もすべて同様になります。
「特権付き」のマークをコードに付ける方法の詳細については、「特権ブロックのための API」を参照してください。
4.3 アクセス制御コンテキストの継承
スレッドが新しいスレッドを生成するときは、新しいスタックが生成されます。新しいスレッドが生成されたときに現在のセキュリティーコンテキストが書き換えられない場合、新しいスレッドの中でAccessController.checkPermission が呼び出されたときのセキュリティーの判断は、新しいスレッドのコンテキストだけに基づいて行われ、親スレッドのコンテキストは考慮されません。
この明確なスタックの考え方そのものはセキュリティー上の問題にはなりませんが、安全なコード (特にシステムコード) を記述する上で、隠れた間違いを起こしやすくなります。経験の浅い開発者は、子スレッド (信頼できないコードを含まないものなど) は、親スレッド (信頼できないコードを含むものなど) から同じセキュリティーコンテキストを継承すると仮定してしまうことが考えられます。これは、親のコンテキストが実際は保存されていない場合、制御対象のリソースに新しいスレッドからアクセスすると (そのリソースを信頼できないコードに渡すと) 予期しないセキュリティーホールの原因となります。
このため、新しいスレッドが生成されるときは、子スレッドの生成時点における親スレッドのセキュリティーコンテキストを子スレッドが確実に自動継承 (スレッドの生成などのコードを通じて) するようにし、それ以降の子スレッドでの checkPermission の呼び出しで、継承した親のコンテキストが考慮されるようにしました。
つまり、論理的スレッドコンテキストは、親のコンテキスト (次のセクションで説明されている AccessControlContext の形式) と現在のコンテキストの両方を含むように拡張され、アクセス権のチェックのためのアルゴリズムは、次のように拡張されます。(前述したように、checkPermission の呼び出しに至るまでには m 個の呼び出し元があります。AccessControlContext の checkPermission メソッドの詳細については、次のセクションで説明します。)
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;
};
// Next, check the context inherited when
// the thread was created. Whenever a new thread is created, the
// AccessControlContext at that time is
// stored and associated with the new thread, as the "inherited"
// context.
inheritedContext.checkPermission(permission);
この継承は、たとえば、孫が親とその親の両方の性質を継承するのと同じように過渡的なものです。また、継承されたコンテキストは、子コンテキストが最初に実行される時点ではなく、子コンテキストが生成された時点で保存されます。継承の機能については API の公の変更はありません。4.4 java.security.AccessControlContext
前述したように、AccessController のcheckPermission メソッドは、現在の実行スレッド内で (継承したコンテキストも含む) セキュリティーチェックを行います。このようなセキュリティーチェックが別のコンテキスト内でだけ可能な場合には、問題が生じます。つまり、あるコンテキスト内で行うべきセキュリティーチェックを、実際には別のコンテキストで行うことが必要な場合があります。たとえば、あるスレッドが別のスレッドにイベントを送ったとき、そのサービスにはコントローラリソースへのアクセスが必要であるのに、要求イベントを処理する後者のスレッドがアクセス制御を行うための適切なコンテキストを持っていないような場合です。
この問題に対処するために、AccessController に getContext メソッドと AccessControlContext クラスが用意されました。getContext メソッドは、現在の呼び出しコンテキストを AccessControlContext オブジェクトに格納して返します。呼び出しの例を次に示します。
AccessControlContext acc = AccessController.getContext();このコンテキストは、適切な情報を取り込み、別のコンテキストからこのコンテキスト情報を調べることにより、アクセス制御の判断を行えるようにします。たとえば、あるスレッドは別のスレッドに要求イベントを送りながら、このコンテキスト情報を提供することができます。AccessControlContext 自体が
checkPermission メソッドを持っており、このメソッドを使って、現在の実行スレッドのコンテキストではなく、カプセル化しているコンテキストに基づいてアクセスの判断を行います。したがって、2 つ目のスレッドは必要な場合に次の呼び出しを行うことにより、適切なセキュリティーチェックができます。
acc.checkPermission(permission);このメソッドの呼び出しは 2 つ目のスレッドで行われますが、1 つ目のスレッドのコンテキストでセキュリティーチェックを行うことと同じことです。
また、あるアクセス制御コンテキストに対して 1 つまたは複数のアクセス権のチェックが必要なときに、どのアクセス権をチェックするかの優先度が不明なことがあります。こうした場合には、コンテキストを値としてとる doPrivileged メソッドを使用できます。
somemethod() {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// Code goes here. Any permission checks from
// this point forward require both the current
// context and the snapshot's context to have
// the desired permission.
}
}, acc);
...normal code here...
AccessController の checkPermission メソッドが利用するアルゴリズムは、これですべてです。現在のスレッドが呼び出し元 1 から数字の昇順で m 個の呼び出し元をトラバースし、呼び出し元 m が checkPermission メソッドを呼び出すとします。アルゴリズム checkPermission は、アクセスが許可されているかどうかを判断するために次のコードを使用します。
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;
};
// Next, check the context inherited when
// the thread was created. Whenever a new thread is created, the
// AccessControlContext at that time is
// stored and associated with the new thread, as the "inherited"
// context.
inheritedContext.checkPermission(permission);
目次 | 前へ | 次へ
Copyright © 1997-1999 Sun Microsystems, Inc. All Rights Reserved.