【我的新手贴】java沙箱之类加载器

 

     java的沙箱模型就是指java的安全模型，沙箱模型允许你下载一些不可靠站点的代码，但是沙箱模型会限制它们对系统的破坏。究竟java沙箱是怎么做到这一点的呢，我们来看看java沙箱的基本组件。
   类装载器结构
   class文件检验器
   java虚拟机的安全特性
   安全管理器和Java API
   这些组件列出的顺序其实也是java沙箱安全模型进行安全措施的步骤。（当然，这其中的类装载器和安全管理器是可以定制的）<o:p></o:p>

类加载器：<o:p></o:p>

      java程序运行的第一步就是通过类加载器加载class文件。

      有几点规则要事先说明：<o:p></o:p>

规则1.在java虚拟机中，在同一个命名空间内的类可以直接进行交互，而不同命名空间的类甚至不能觉察到彼此的存在。<o:p></o:p>

规则2.从1.2开始，除启动类装载器以外的每一个类装载器，都有一个“双亲”类装载器，在某个特定的类装载器试图以常用方式装载类以前，它都会默认的把这个任务委派给它的双亲-请求它的双亲去装载这个类，如果它的双亲没有能力转载，则只能试图自己去装载这个类。<o:p></o:p>

我们来举一个例子来描述类的加载过程。<o:p></o:p>

    <o:p></o:p>

    假设网络类加载器发出一个转载Volcano类的请求，按照规则2 Volcano的加载会一直逐步委派到启动加载器，但是Volcano不是核心API，因此Volcano的加载的任务会再次让网络类加载器去加载，假设通过网络正确的下载了Volanno类，这样Volcano类会在以后的执行过程中会被使用。<o:p></o:p>

    我们再进一步假设Volcano类有一个方法被调用，方法引用了java.util.HashMap,由于是第一次引用，虚拟机会请求装载Volcano的类装载器去转载，同样通过规则会让启动类加载器去加载这个HashMap类。<o:p></o:p>

   从上述的过程我们可以得出：<o:p></o:p>

  1.假如我们自己编写了一个java.util.HashMap的类，它是不可能被加载的，即便是一个病毒去伪装成java.util.HashMap，还是没法用，原因很简单，类加载器总是去加载真正的核心API中的HashMap。<o:p></o:p>

    你也许会想能不能在把HashMap加载后我再用假的去替换这个真的HashMap，呵呵，当然可以，前提是你要知道虚拟机的设计，这样才能知道存放HashMap存放的地址，这一点也是java结构化内存操作的安全性考虑。<o:p></o:p>

    我们继续Volcano类的调用，聪明的黑客或许会想到如何利用规则1伪装一个具有访问权限的类，比如java.lang.hacker,这个hacker按照规则1可是拥有访问java.lang包中的任何权限的啊，好可怕。<o:p></o:p>

      规则三：Java虚拟机只把特殊访问的权限授予由同一个类加载器装载的同一个包中的类，即他们属于同一个“运行时包”。“运行时包”这个是在java 虚拟机第二版规范中第一次提出，它指由同一个类型加载器转载的，属于同一个包的，多个类型的集合。<o:p></o:p>

   很显然java.lang.hacker和java.lang中的其他类型属于同一个运行时包的，因此没有访问权限。<o:p></o:p>

     说到这里也许会想，我要是修改java核心库是不是就可以瞒天过海了，当然可以了。但是java安全还有其他的机制去防范，但是也注意这仅仅是机制，你死活要主动的破坏也不是不可能。<o:p></o:p>

     注：绝大部分内容来自《深入java虚拟机》，书上只讲这么多，我也只知道这么多，希望抛砖引玉。<o:p></o:p>

<o:p> </o:p>

排版。。。要么不要排
要么好好排一下