2

Policy次のように Policy クラスを拡張する独自のクラスを定義して、カスタムを設定したいと考えています。

public class MyPolicy extends Policy {

    public MyPolicy() {
        super();
    }

    @Override
    public PermissionCollection getPermissions(ProtectionDomain domain) {
        // return PermissionCollection with no permissions
        PermissionCollection pc = new PermissionCollection();
        return pm;
    }
}

次に、アプリケーションの開始時にカスタムPolicyクラスを設定SecurityManagerし、新しいポリシーが有効になるように有効にします。

Policy.setPolicy(new MyPolicy());
System.setSecurityManager(new SecurityManager());

上記の問題は、それが機能しないことです。上記の例の考え方は、アプリケーションがあらゆる種類の許可を必要とすることを実行できないようにするポリシーを導入することです。たとえば、アプリケーションを実行すると、次のようになります。

System.getenv();

上記の結果、AccessControlExceptionによってスローされるはずSecurityManagerです。代わりに、私のアプリケーションは問題なく動作します。ただし、ポリシーを初期化すると、SecurityManager次のようになります。

// setting the policy twice intentionally 
Policy.setPolicy(new MyPolicy());
Policy.setPolicy(new MyPolicy());
System.setSecurityManager(new SecurityManager());

次にSystem.getenv()、実際に実行すると、期待される結果が得られAccessControlExceptionます。

説明が必要な質問/懸念事項は次のとおりです。

  • SecurityManager の設定後にポリシーを有効にするために、ポリシーを 2 回設定する必要があるのはなぜですか?
  • 上記の問題は何らかのバグですか、それとも Policy クラスは意図的にこのように動作するように設計されていますか (もしそうなら、なぜですか?)。
4

1 に答える 1

1

実装自体の一部が信頼されていない可能性がある場合、スタック インスペクション ベースのセキュリティ メカニズムを扱う「興味深い」問題があります。nullクラスローダーのチェックがバイパスされるため、ブートストラップクラスで実装すると、はるかに簡単になります。

setPolicy初めて実行するときProtectionDomainは、Policy実装のすべての権限が与えられます。したがって、すべてのコードに特権が与えられます-望んでいたものではありません.

後続のsetPolicy呼び出しの場合、前者は実装Policyの権限を提供します。あなたの場合、すべてのコードに空の権限が与えられます。（おそらくこれを呼び出す必要があります-厄介なAPI。また、これは抽象クラスであるため、コンパイルしないでください。）PolicyProtectionDomainPermissionCollectionsetReadOnly

したがって、別のクラス ローダーを使用して、信頼できないコードとセキュリティ メカニズムをロードすることをお勧めします。

あなただけが、何もアクセス許可を持っていないと仮定して、多くのことを行ったり壊したりしたことがあるでしょう。ブート クラスは、nullクラス ローダーによりパスを取得します。たとえば、クラスをロードするにはおそらくパーミッションが必要なので、そこにあるすべてを拒否したくはありません。

通常のポリシー ファイル構成を使用してポリシーを構成する方がはるかに優れています。

于 2015-07-16T17:23:43.380 に答える