Policy.setPolicy()似乎无法正常工作

时间:2015-07-16 15:44:09

标签: java security securitymanager java-security

我想通过定义扩展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后生效?
  • 上面是否存在某种错误,或者策略类是故意设计成这样的行为(如果是这样 - 为什么?)?

1 个答案:

答案 0 :(得分:1)

有趣的"当部分实现本身可能不受信任时,处理基于堆栈检查的安全机制的问题。使用引导类实现它时会更容易,因为null类加载器会绕过检查。

第一次setPolicy时,ProtectionDomain实施的Policy将获得所有权限。所以你的所有代码都是特权 - 而不是你想要的。

对于后来的setPolicy来电,之前的Policy会提供Policy实施ProtectionDomain的权限。在您的情况下,导致您的所有代码都具有空PermissionCollection权限。 (你应该在这个讨厌的API上调用setReadOnly。它也是一个抽象类,所以不应该编译。)

因此,您可能希望使用单独的类加载器来加载不受信任的代码和安全机制。

只有你没有任何权限,只有你可能已经破坏了很多东西。引导类因为null类加载器而获得通过。例如,加载类可能需要权限,因此您不想拒绝那里的所有内容。

使用常规策略文件配置配置策略要好得多。