Java安全机制之一——SecurityManager和AccessController
前言：
在看socket相关代码的时候，AbstractPlainSocketImpl中的一段代码吸引了我，其实之前见过很多次类似的代码，但一直不想去看，只知道肯定和权限什么的相关，这次既然又碰到了就研究一下，毕竟也不能对java基本代码一无所知。
static {
java.security.AccessController.doPrivileged(
new java.security.PrivilegedAction<Void>() {
public Void run() {
System.loadLibrary("net");
return null;
}
});
}
一些概念:
在jdk1.0的时代，applet依然是前端的一种可用的技术方案，比如可以嵌入在网页里运行。那个时候jdk的设计者们认为本地代码是安全的、远端代码是有风险的，而applet就是属于远端代码。因此，为了保证用户主机的安全和隐私，设计者参考了沙箱的思想，依托于当时jdk的体量很小，使用SecurityManager来分隔本地代码和远程代码，一个有权限，一个没有权限。
当时还出现了签名相关的机制(本文不关心，所以没做了解），随着java发展，1.1的时候出现了JAVABEAN、JDBC、反射等新概念，于是有了更多的新权限。设计者发现完全授予本地代码所有权限变得不合理，在1.2的时候重构了SecurityManager，变成了现在这样以最小粒度控制权限。这个时候的SecurityManager有两个功能，一是防御远程代码、二是防御本地代码的漏洞。
不知道是什么时候起，安全机制引入了域（ProtectDomain）的概念，也可以视作将一个大沙箱拆分为多个小沙箱。一个域对应一个沙箱，不同的代码（Codesource）被划分到不同域中，不同的域有着不同的权限（Permission），就像下图一样。同时可以给不同的域配置不同的权限，静态和动态均可，这个配置被称为策略(Policy)。
注意！
在JDK20和JDK21的security-guide中都提到了，和SecurityManager与之相关的api已被弃用，并将在未来的版本中删除。SecurityManager没有替代者。有关讨论和备选方案，请参阅JEP 411: Deprecate the Security Manager for Removal。
AccessController
AccessController主要有两个功能，对应的核心方法也是两类
checkPermission(校验是否存在权限)
public static void checkPermission(Permission perm)
throws AccessControlException
{
AccessControlContext stack = getStackAccessControlContext();
// if context is null, we had privileged system code on the stack.
//...其他获取context方法
AccessControlContext acc = stack.optimize();
acc.checkPermission(perm);
}
调用该方法时，一般会new一个期望的权限，然后作为入参传入checkPermission方法。
FilePermission perm = new FilePermission("C:\\Users\\Administrator\\Desktop\\liveController.txt", "read");
AccessController.checkPermission(perm);
注意，校验权限的时候会校验调用链路径上所有类的权限；假如调用链是从i开始，一直调用到m，校验逻辑如下
for (int i = m; i > 0; i--) {
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)
if (limited permissions were specified in the call to doPrivileged) {
for (each limited permission) {
if (the limited permission implies the requested permission)
return;
}
} else
return;
}
}
代码执行的时候，每一次方法的调用都代表着一次入栈，而权限校验的时候则正好是从栈顶开始，依次判断每个栈帧是否具有权限，一直到栈底。
doPrivileged(临时授权)
public static native <T> T doPrivileged(PrivilegedAction<T> action);
这个方法的功能是将当前类所拥有的权限，能且仅能临时赋予其上游调用方。
在这个场景下，必然存在多个域，且只有某些域拥有权限A，但是其他域并没有这个权限。在java语言中很容易出现这个情况，比如我们调用一些第三方jar包的方法，三方jar包还能调用别的三方jar包，这种场景很有可能只有最底层的方法所对应的域拥有权限。此时为了方法的成功，就可以使用该方法。
使用的时候就是将代码逻辑放入AccessController.doPrivileged中即可，如下述代码一般。
//项目B，会打成security-demo.jar
public class PermissionDemo {
/**
* 使用特权访问机制
* @param file
*/
public void runWithOutPermission(String file){
AccessController.doPrivileged((PrivilegedAction<String>) () -> {
//hutool的FileUtil
String s = FileUtil.readString(file, "utf-8");
System.out.println(s);
return s;
});
}
}
//项目A，引入security-demo.jar
public class Aperson {
public static void main(String[] args) {
new PermissionDemo().runWithOutPermission("C:\\Users\\Administrator\\Desktop\\test.txt");
}
}
这里需要注意的是，AccessController.doPrivileged所在的当前类也需要拥有权限。以这个例子为例，文件读写是在hutool的FileUtil中执行，hutool对应的是域C；PermissionDemo对应的是域B，且会将自身权限向上传递；而Aperson对应的是域A。这个例子中，想要Aperson执行成功，必须是域C和域B都拥有test.txt的read权限。
对应的policy如下
grant codeBase "file:/C:/Users/Administrator/.m2/repository/cn/hutool/hutool-all/5.7.11/-"{
permission java.io.FilePermission "C:\\Users\\Administrator\\Desktop\\*", "read";
};
grant codeBase "file:/C:/Users/Administrator/.m2/repository/xxx/xxx/security-demo/-"{
permission java.io.FilePermission "C:\\Users\\Administrator\\Desktop\\*", "read";
};
从栈帧的角度来看的话，判断到doPrivilege对应的那层之后，校验就直接返回了，不校验下面层是否存在权限。
ProtectDomain
protectDomain类由codeSource和permission构成
CodeSource
类的来源，一般为jar包路径或者classpath路径（target/classes）
因为所有类在通过ClassLoader引入的，所以ClassLoader知道类的基本信息，在defineClass时，将CodeSource和Permission进行了绑定。同理，由于类必须通过ClassLoader加载，对于使用自定义ClassLoader加载的类，就只有那个类加载器知道对应的CodeSource和permission。因此，不同的类加载器本身就属于不同的域。
Permission
Java抽象出的顶层的类，核心方法是implies，该方法用来判断当前线程是否隐含指定权限，由各自的子类实现。子类实现过多，这里就不列举了。
PermissionCollection本质是个list，里面是某一类权限的多个实例，比如文件夹A-读权限，文件夹B-写权限，文件夹C-读写权限。
Permissions核心是一个map,key是Permissoin子类,value是PermissionCollection
SecurityManager
SecurityManage里有一堆check方法，调用的是AccessController.checkPermission方法，入参就是Permission各个子类的实例化。
开启方式：
隐性：启动时添加-Djava.security.manager
显性：System.setSecurityManager
public class NoShowTest {
static class CustomManager extends SecurityManager{
@Override
public void checkRead(String file) {
throw new AccessControlException("无权限访问");
}
}
public static void main(String[] args) {
System.setSecurityManager(new CustomManager());
System.getSecurityManager().checkRead("C:\\Users\\Administrator\\Desktop\\liveController.txt");
}
}
Policy
启动时通过 -Djava.security.policy=xxxx\custom.policy，如果没有指定，则默认使用jdk路径下\jre\lib\security\java.policy
参考：
Java安全:SecurityManager与AccessController - 掘金
Java沙箱机制的实现——安全管理器、访问控制器 - 掘金
第21章-再谈类的加载器
https://openjdk.org/jeps/411
https://docs.oracle.com/en/java/javase/20/security/java-security-overview1.html#GUID-BBEC2DC8-BA00-42B1-B52A-A49488FCF8FE
AccessController.doPrivileged - 山河已无恙 - 博客园
