Java的沙箱机制原理入门

程序员写一个Java程序，默认的情况下你可以访问任意的机器资源，比如读取，删除一些文件或者网络操作等。当你把程序部署到正式的服务器上，系统管理员要为服务器的安全承担责任，那么他可能不敢确定你的程序会不会访问不该访问的资源，为了消除潜在的安全隐患，他可能有两种办法：1，让你的程序在一个限定权限的帐号下运行；

2.利用Java的沙箱机制来限定你的程序不能为非作歹。我们这里主要谈谈后一种方法。

组成沙箱的基本组件如下：

1.类装载器体系结构

其中类装载器在3个方面对Java沙箱起作用：a.它防止恶意代码去干涉善意的代码；b.它守护了被信任的类库边界；c. 它将代码归入保护域，确定了代码可以进行哪些操作。

虚拟机为不同的类加载器载入的类提供不同的命名空间，命名空间由一系列唯一的名称组成，每一个被装载的类将有一个名字，这个命名空间是由Java虚拟机为每一个类装载器维护的，它们互相之间甚至不可见。

类装载器采用的机制是双亲委派模式。a. 从最内层JVM自带类加载器开始加载，外层恶意同名类得不到先加载而无法使用；b.由于严格通过包来区分了访问域，外层恶意的类通过内置代码也无法获得权限访问到内层类，破坏代码就自然无法生效。

2.class文件检验器

3.java虚拟机中内置的安全特性

Java语言与C++相比它的语法更加简单清晰，取消了运算符重载，多重继承。能降低开发人员犯错误的几率，帮助他们写出更安全的代码。

Java中去除了容易出错的"指针"，用列表、堆、哈希表等结构来代替。

Java中所有的数组访问都必须先检查是否越界。

Java要求所有的变量在初始化以前不能使用，对于基本数据类型变量都会自动地赋给某个初始值，避免了未初始化变量获取内存信息。所有这些都使得程序不能访问任意的内存地址。

Java分配内存对于开发人员来说是透明的，开发人员使用new方法新建对象,这时候虚拟机就会从堆内存中找到合适的内存空间。而对于内存的回收，Java避免了开发人员明确干预对象的回收，比如C的free或C++的delete命令，避免了开发人员无意间对内存的破坏。Java采用虚拟机的"垃圾回收"机制来实现的内存自动管理，释放不再被使用的内存资源，Java的内存回收器目的就是找到不再引用的对象，释放内存空间，并且需要整理内存的碎片空间，尽量避免出现"内存不足"的情况。

4.安全管理器和Java API

讲了些签名证书的东西，公钥私钥...

怎样给一个程序设置一个“沙箱”呢？这个设置应该是避免改动程序代码的，而且是简单易行的。根据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的类加载器机制保证了你不能去替代或者干涉它的核心类库。