程序员写一个Java程序,默认的情况下你可以访问任意的机器资源,比如读取,删除一些文件或者网络操作等。当你把程序部署到正式的服务器上,系统管理员要为服务器的安全承担责任,那么他可能不敢确定你的程序会不会访问不该访问的资源,为了消除潜在的安全隐患,他可能有两种办法:1,让你的程序在一个限定权限的帐号下运行;
2.利用Java的沙箱机制来限定你的程序不能为非作歹。我们这里主要谈谈后一种方法。
怎样给一个程序设置一个“沙箱”呢?这个设置应该是避免改动程序代码的,而且是简单易行的。根据Java的文档,我们了解到只需简单的两个步骤。
步骤一.加一个运行参数,就可以让一个程序在沙箱里运行:
java -Djava.security.manager -jar myapp.jar
步骤二.设置具体的权限,比如创建自己的策略文件myapp.policy:
grant codeBase "file:${user.dir}/myapp.jar" {
permission java.io.FilePermission "${user.dir}${/}*", "read";
};
这个设置的意思是,从myapp.jar载入的代码,对当前目录下的所有文件有“读”的权限。
做完这两个步骤后,运行命令:
java -Djava.security.manager -Djava.security.policy==myapp.policy -jar myapp.jar
就可以保证程序只拥有你指明的权限。当访问其他资源时,会抛出类似"access denied"的异常。系统默认的策略文件是${java.home}/jre/lib/security/java.policy,它拥有的权限非常少,而且都与访问系统资源无关。
那么问题随之而来,这一切是怎么实现的?检查的代码在哪里,又是谁来开发的这些代码?
答案是:这是SUN干的,SUN早把这些检查的代码插入到所有访问系统资源的API里面了。
举一个读取文件的例子,比如:
BufferedReader br = new BufferedReader(new FileReader(fileName));
String line = br.readLine();
当你运行到第一行,继续调试进Java API源代码里,就可以碰到下面的一段代码:
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead(name);
}
这里的代码表示,如果安装了SecurityManager,那么将进行安全检查(是否对这个文件具有读的权限)。而当你加上运行参数-Djava.security.manager,即表示安装了SecurityManager。这里和上面的第一个步骤对应。
继续调试进去,看到下面的代码:
checkPermission(new FilePermission(file,
SecurityConstants.FILE_READ_ACTION));
很明显,这和上面的第二个步骤对应,FilePermission即为java.io.FilePermission,FILE_READ_ACTION即为“read”。
那么codeBase和什么对应呢?
codeBase涉及到ClassLoader方面的知识了,简单的说,ClassLoader加载一些代码的时候,它会把代码来源的信息保存下来,这些信息结合从策略文件里读取的信息,系统就可以来做出决策了。
细节总是复杂的,但在理解这个原理后去深入细节,就能起到引领的作用。这里最让人疑惑的地方不是策略文件的配置和规则,而是谁在决策,在什么时候决策。可能有人提出一个问题,如果我不用SUN的API,我自己去写一些代码访问机器上的资源,那不就可以绕开“沙箱”了吗?理论上是可以的,但只要你写的是Java代码,并且仍使用SUN的虚拟机,那么你就没有这个机会。SUN的类加载器机制保证了你不能去替代或者干涉它的核心类库。
2.利用Java的沙箱机制来限定你的程序不能为非作歹。我们这里主要谈谈后一种方法。
怎样给一个程序设置一个“沙箱”呢?这个设置应该是避免改动程序代码的,而且是简单易行的。根据Java的文档,我们了解到只需简单的两个步骤。
步骤一.加一个运行参数,就可以让一个程序在沙箱里运行:
java -Djava.security.manager -jar myapp.jar
步骤二.设置具体的权限,比如创建自己的策略文件myapp.policy:
grant codeBase "file:${user.dir}/myapp.jar" {
permission java.io.FilePermission "${user.dir}${/}*", "read";
};
这个设置的意思是,从myapp.jar载入的代码,对当前目录下的所有文件有“读”的权限。
做完这两个步骤后,运行命令:
java -Djava.security.manager -Djava.security.policy==myapp.policy -jar myapp.jar
就可以保证程序只拥有你指明的权限。当访问其他资源时,会抛出类似"access denied"的异常。系统默认的策略文件是${java.home}/jre/lib/security/java.policy,它拥有的权限非常少,而且都与访问系统资源无关。
那么问题随之而来,这一切是怎么实现的?检查的代码在哪里,又是谁来开发的这些代码?
答案是:这是SUN干的,SUN早把这些检查的代码插入到所有访问系统资源的API里面了。
举一个读取文件的例子,比如:
BufferedReader br = new BufferedReader(new FileReader(fileName));
String line = br.readLine();
当你运行到第一行,继续调试进Java API源代码里,就可以碰到下面的一段代码:
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkRead(name);
}
这里的代码表示,如果安装了SecurityManager,那么将进行安全检查(是否对这个文件具有读的权限)。而当你加上运行参数-Djava.security.manager,即表示安装了SecurityManager。这里和上面的第一个步骤对应。
继续调试进去,看到下面的代码:
checkPermission(new FilePermission(file,
SecurityConstants.FILE_READ_ACTION));
很明显,这和上面的第二个步骤对应,FilePermission即为java.io.FilePermission,FILE_READ_ACTION即为“read”。
那么codeBase和什么对应呢?
codeBase涉及到ClassLoader方面的知识了,简单的说,ClassLoader加载一些代码的时候,它会把代码来源的信息保存下来,这些信息结合从策略文件里读取的信息,系统就可以来做出决策了。
细节总是复杂的,但在理解这个原理后去深入细节,就能起到引领的作用。这里最让人疑惑的地方不是策略文件的配置和规则,而是谁在决策,在什么时候决策。可能有人提出一个问题,如果我不用SUN的API,我自己去写一些代码访问机器上的资源,那不就可以绕开“沙箱”了吗?理论上是可以的,但只要你写的是Java代码,并且仍使用SUN的虚拟机,那么你就没有这个机会。SUN的类加载器机制保证了你不能去替代或者干涉它的核心类库。