上下文

Question

上下文

我正在编写一个Java系统，其中代码在非常严格的沙箱中执行。一个查询（由一个或多个类组成）应该只允许在执行期间访问一个文件夹（以及文件夹中包含的子文件夹和文件）。

我通过使用SecurityManager和每个查询执行的新ClassLoader来强制执行沙盒操作。使用ClassLoader在defineClass中定义类时，我会传递一个ProtectionDomain，其中包含应授予的文件读取权限。

由于并非调用堆栈上的所有objets都具有所需的权限，因此查询中的读取操作将在AccessController.doPrivileged(...) - 块中运行。

问题

当我直接从AccessController.checkPermission(...)块中调用doPrivileged(...)时，它会以静默方式返回
当我致电System.getSecurityManager().checkPermission(...)，将请求转发给AccessController时，AccessController会抛出异常。
通过ProtectionDomain致电AccessController时，SecurityManager似乎迷路了？
受限制的文件操作（如创建java.io.FileReader），直接调用SecurityManager而不是AccessController。 如何通过AccessController调用SecurityManager来尊重调用ProtectionDomain - 阻止的类的doRestricted(...)？
可能是SecurityManager本身没有所需的权限吗？因此，通过夹在特权代码之间的调用堆栈中，AccessController生成一个没有的特权联合？

下面是一个示例部分：

AccessController.doPrivileged(new PrivilegedAction<QueryResult>() {
  public QueryResult run() {
    String location = folderName + "/hello";
    FilePermission p = new FilePermission(location, "read");
    try {
      AccessController.checkPermission(p); // Doesn't raise an exception
      System.out.println("AccessController says OK");
      System.getSecurityManager().checkPermission(p);  // Raises AccessControlException
      System.out.println("SecurityManager says OK");
    } catch (AccessControlException e) {
      System.out.println("### Not allowed to read");
    }
    return null;
  }
});

程序生成的输出，包括堆栈跟踪的部分（PATH替换使用的长路径名）：

AccessController says OK
Asked for permission: ("java.io.FilePermission" "PATH/hello" "read")
java.security.AccessControlException: access denied ("java.io.FilePermission" "PATH/hello" "read")
  at java.security.AccessControlContext.checkPermission(AccessControlContext.java:366)
  at java.security.AccessController.checkPermission(AccessController.java:560)
  at com.aircloak.cloak.security.CloakSecurityManager.checkPermission(CloakSecurityManager.java:40)
  at com.dummycorp.queries.ValidQuery$1.run(ValidQuery.java:23)
  at com.dummycorp.queries.ValidQuery$1.run(ValidQuery.java:1)
  at java.security.AccessController.doPrivileged(Native Method)
  at com.dummycorp.queries.ValidQuery.run(ValidQuery.java:16)
  at com.aircloak.cloak.security.CloakSecurityManagerTest$1.run(CloakSecurityManagerTest.java:75)
  at java.lang.Thread.run(Thread.java:722)

CloakAccessController.checkPermission(...)实施可能也很有意义。它看起来像这样：

public void checkPermission(Permission perm) {
  if (Thread.currentThread().getId() == this.masterThread) {
    return;
  } else {
    System.out.println("Asked for permission: "+perm.toString());
  }
  AccessController.checkPermission(perm);
}

它的作用主要是绕过了创建它的线程的安全限制。

我的java.policy文件的内容是标准MacOSX系统的内容。我相信它不包含任何非标准的更改。

Answer 1

我觉得有点尴尬地回答我自己的问题，但我找到了正确的解决方案，并且认为在这里添加它是正确的，所以如果有人在这个问题上遇到困难，将来会记录下来。

<强> TL; DR ：

我的自定义SecurityManager没有正确的权限。由于它位于调用doPrivileged(...) - 块和AccessController的类之间的callstack上，因此权限的交集完全没有权限。

长版

Java安全模型的工作原理如下。当AccessController验证是否允许类调用某个方法时，它会查看从callstack顶部到底部的权限。如果callstack中的每个条目都具有该权限，则允许该操作。

这是一个任意例子，其中一切都很好：

+-----------+-------------------+-----------------------+
| Callstack | Class permissions | Permissions in effect |
+-----------+-------------------+-----------------------+
| Some      | {Read,Write}      | {Read}                |
| Other     | {Read}            | {Read}                |
+-----------+-------------------+-----------------------+

现在，就我的问题而言，callstack中的较低层根本没有权限。因此，我们最终会得到一张这样的图片，其中顶部的query实际上没有权限。

+-----------+-------------------+-----------------------+
| Callstack | Class permissions | Permissions in effect |
+-----------+-------------------+-----------------------+
| Query     | {Read}            | {}                    |
| Other     | {}                | {}                    |
+-----------+-------------------+-----------------------+

您可以使用doPrivileged(...) - 块解决此问题。这允许通过callstack的权限搜索在调用特权操作的条目处结束：

+-----------+-------------------+-----------------------+
| Callstack | Class permissions | Permissions in effect |
+-----------+-------------------+-----------------------+
| Query     | {Read}            | {Read}                |
| Other     | {}                | {}                    |
+-----------+-------------------+-----------------------+

这就是我在查询中调用AccessController.checkPermission(...)时一切正常的原因。毕竟它确实拥有正确的权限。（Un）幸运的是java API（为了向后兼容），总是调用SecurityManager。就我而言，SecurityManager根本没有任何特权。因为它实际上是在进行特权调用的查询和AccessController之间的callstack上，所以净结果权限是none：

+-----------------+-------------------+-----------------------+
|    Callstack    | Class permissions | Permissions in effect |
+-----------------+-------------------+-----------------------+
| SecurityManager | {}                | {}                    |
| Query           | {Read}            | {Read}                |
| Other           | {}                | {}                    |
+-----------------+-------------------+-----------------------+

<强>解决方案

解决方案是为SecurityManager提供一组基本权限。因此，授予Query的权限确实是所需的权限：

+-----------------+---------------------+-----------------------+
|    Callstack    |  Class permissions  | Permissions in effect |
+-----------------+---------------------+-----------------------+
| SecurityManager | {Read,Write,Delete} | {Read}                |
| Query           | {Read}              | {Read}                |
| Other           | {}                  | {}                    |
+-----------------+---------------------+-----------------------+

唷！那真是一口气！希望这对那里的人有用：）

Answer 2

我认为这里的问题在于您为ProtectionDomain提供SecurityManager的方式。

如果您想自己加载类，并且能够使用SM，则应扩展SecureClassLoader。该类提供了带模板的方法：

protected Class defineClass(String name, byte[] b, int off, int len, CodeSource cs)

您应该为您的班级提供CodeSource。然后是另一种方法：

   protected  PermissionCollection getPermissions(CodeSource codesource)

对于来自给定CodeSource的课程，将返回PermissionCollection。这就是为动态加载的类实现动态权限的方式。

AccessController没有将类的ProtectionDomain考虑在内

上下文

问题

2 个答案:

<强> TL; DR ：

长版

<强>解决方案