Java沙箱實現(xiàn)是重寫類加載器和安全管理器,通過設(shè)置的全局安全管理器來控制執(zhí)行程序的權(quán)限
說明: 安全策略只對安裝安全管理器之后的類生效,之前的類不再此管理范圍之內(nèi),利用這一點可以預(yù)先設(shè)置我們需要的操作,而對某個點之后的所有非法操作進行權(quán)限設(shè)置.

?

說明，本文部分內(nèi)容轉(zhuǎn)自：http://galaxystar.javaeye.com/blog/225615
參考書籍：《Inside the Java Virtual Machine,Second Edition》

組成Java沙箱的基本組件如下：

·類加載體系結(jié)構(gòu)
·class文件檢驗器
·內(nèi)置于Java虛擬機（及語言）的安全特性
·安全管理器及Java API

Java安全模型的前三個部分——類加載體系結(jié)構(gòu)、class文件檢驗器、Java虛擬機（及語言）的安全特性一 起達(dá)到一個共同的目的：保持Java虛擬機的實例和它正在運行的應(yīng)用程序的內(nèi)部完整性，使得它們不被下載的惡意代碼或有漏洞的代碼侵犯。相反，這個安全模 型的第四個組成部分是安全管理器，它主要用于保護虛擬機的外部資源不被虛擬機內(nèi)運行的惡意或有漏洞的代碼侵犯。這個安全管理器是一個單獨的對象，在運行的 Java虛擬機中，它在對于外部資源的訪問控制起中樞作用。

類加載體系結(jié)構(gòu)
類加載器要加載一個類，它首先檢查此類是否已被加載，然后再委托雙親加載器加載此類，它的雙親加載器再委托它的雙親，這樣一直委托到啟 動加載器，啟動加載器在從核心API查找此類，如果有就返回此類，否則就他的子加載器就查找此類，如果都沒有就拋出ClassNotFound的異常。如 下圖所示：

這種委托雙親的模式好處是：啟動類加載器可以搶在標(biāo)準(zhǔn)擴展類裝載器之前去裝載類，而標(biāo)準(zhǔn)擴展類裝載器可以搶在類路徑加載器之前去裝載那個類，類路徑 裝載器又可以搶在自定義類加載器之前去加載它。所以Java虛擬機先從最可信的Java核心API查找類型，這是為了防止不可靠的類扮演被信任的類，試想 一下，網(wǎng)絡(luò)上有個名叫java.lang.Integer的類，它是某個黑客為了想混進java.lang包所起的名字，實際上里面含有惡意代碼，但是這 種伎倆在雙親模式加載體系結(jié)構(gòu)下是行不通的，因為網(wǎng)絡(luò)類加載器在加載它的時候，它首先調(diào)用雙親類加載器，這樣一直向上委托，直到啟動類加載器，而啟動類加 載器在核心Java API里發(fā)現(xiàn)了這個名字的類，所以它就直接加載Java核心API的java.lang.Integer類，然后將這個類返回，所以自始自終網(wǎng)絡(luò)上的 java.lang.Integer的類是不會被加載的。

但是如果這個移動代碼不是去試圖替換一個被信任的類（就是前面說的那種情況），而是想在一個被信任的包中插入一個全新的類型，情況會怎樣呢？比如一 個名為java.lang.Virus的類，經(jīng)過雙親委托模式，最終類裝載器試圖從網(wǎng)絡(luò)上下載這個類，因為網(wǎng)絡(luò)類裝載器的雙親們都沒有這個類（當(dāng)然沒有 了，因為是病毒嘛）。假設(shè)成功下載了這個類，那你肯定會想，Virus和lang下的其他類痛在java.lang包下，暗示這個類是Java API的一部分，那么是不是也擁有修改Java.lang包中數(shù)據(jù)的權(quán)限呢？答案當(dāng)然不是，因為要取得訪問和修改java.lang包中的權(quán) 限，java.lang.Virus和java.lang下其他類必須是屬于同一個運行時包的，什么是運行時包？運行時包是指由同一個類裝載器裝載的、屬 于同一個包的、多個類型的集合。考慮一下，java.lang.Virus和java.lang其他類是同一個類裝載器裝載的嗎？不是 的！java.lang.Virus是由網(wǎng)絡(luò)類裝載器裝載的！
class文件校驗器，通過四趟掃描，保證了class文件正確
第一趟是，檢查class文件的結(jié)構(gòu)是否正確。比較典型的就是，檢查class文件是否以魔數(shù)OxCAFEBABE打頭。
通過這趟檢查，可以過濾掉大部分可能損壞的，或者壓根就不是class的文件，來冒充裝載。
第二趟是，檢查它是否符合java語言特性里的編譯規(guī)則。比如發(fā)現(xiàn)一個類的超類不是Object，就拋出異常。
第三趟是，檢查字節(jié)碼是否能被JVM安全的執(zhí)行，而不會導(dǎo)致JVM崩潰。這里提到了一個停機的問題。內(nèi)容是這樣的，“即不可能寫出一個程序，用 它來判定作為其輸入而讀入的某個程序，是否會停機”。意思是，不可能寫一個程序，讓它告訴你，另外一個程序會不會中斷或崩潰。

第四趟是，符號引用驗證。一個類文件，它會包含它引用的其他類的全名和描述符，并跟他們建立符號引用（一種虛擬的，非物理連接的方式）。當(dāng)程序第一 次執(zhí)行到需要符號引用的位置時，jvm會檢查這個符號鏈接的正確性，然后建立真正的物理引用(直接引用)。

內(nèi)置于Java虛擬機（及語言）的安全特性

這些都是基礎(chǔ)的java語言特性，他們降低了java程序出現(xiàn)內(nèi)存混亂，崩潰的幾率。

·結(jié)構(gòu)化內(nèi)存訪問（不使用指針，一定程度上讓黑客無法篡改內(nèi)存數(shù)據(jù)）
·自動垃圾收集
·數(shù)組邊界檢查
·空引用檢查
·數(shù)據(jù)類型安全

安全管理器及Java API
這是安全沙箱中，離我們程序員最接近的一環(huán)。
securityMananger，是一個api級別的，可自定義的安全策略管理器，它深入到j(luò)ava api中，在各處都可以見到它的身影。比如SecurityClassLoader。
默認(rèn)情況下，java應(yīng)用程序是不設(shè)置 securityManager 實例的(意味著不會起到安全檢查)，這個實例需要我們在程序啟動時通過 System.setSecurityManager 來設(shè)置。
一般情況下，檢查權(quán)限是，通過 SecurityManager.checkPermission(Permission perm) 來完成的。外部程序通過，創(chuàng)建Permission實例，傳遞給前面的check。
Permission是一個抽象類，需要繼承它實現(xiàn)不同的權(quán)限驗證，比如 FilePermission，代表對某個文件的讀寫權(quán)限。
new FilePermission("test.txt", "read")

你可以將這個實例，扔給 SecurityManager,檢查是否可讀text.txt這個文件

轉(zhuǎn)載于:https://www.cnblogs.com/liaomin416100569/archive/2010/11/12/9331577.html

總結(jié)

以上是生活随笔為你收集整理的java 沙箱的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。