2011-11-26 86 views
4

我正在設計一個系統來加載,處理和支持Java應用程序中的插件。我覺得一個特點是在它可以被部署之前絕對至關重要的是能夠建立一個安全的環境,在這個環境中插件被限制在允許的範圍內。如何安全地實現Java插件安全性?

我不明白如何以編程方式使用政策文件但不運行在推出-Djava.security.manager參數。所以現在就結束了。

我的下一個想法是覆蓋所有我的SecurityManager在誰可以執行他們自己的SecurityManager的子類,地點的限制關心的方法。

的問題,然後大作,只有這樣,才能找出誰是問這個權限是通過線程ID檢查。所以,我設計了一個系統,所有的插件線程都駐留在PluginThreads線程組中。

這工作......直到一切開始爆炸。問題在於一些被封鎖的東西是由Sun的代碼執行的內部操作。

所以即使是最基本的操作,如打開一個窗口,因爲我的保安經理被拒絕訪問Sun的代碼會失敗。這裏使用我的Thread檢查方法是沒有問題的,因爲Sun的代碼是在PluginThreads組內執行的。

所以我需要知道的是:

1)是否有可能是一個辦法,我可以找出其內的呼叫從使用當前線程到來的背景下?

2)有沒有更好的方法來做到這一點,我不知道?

3)如果該方法涉及策略文件,那麼如何將它們加載到代碼中?

4)是否有你能想到的,以防止太陽內部的Java代碼被封鎖任何其他方法?

回答

0

您需要使用java.security.AccessController/AccessControlContextSecurityManager。該API支持類型爲Object的上下文對象,但實際上您需要使用AccessControlContext。要爲用戶代碼提供正確的權限,請通過SecureClassLoader的子類提供相關的ProtectionDomainURLClassLoader.newInstance是您必須正確使用的合理示例)。

對於GUI應用程序(例如,這包括任何使用java.beans的特定部分的任何內容),您還需要處理AppContext(在Java庫的「Sun」實現中)。這不是一個公共API。

線程和線程組不是管理安全性的好方法。不幸的是,這是如何進行隔離的一部分。

+0

是的我注意到線程檢查是一個糟糕的處理安全的方式。 AccessControlContext是否不會干擾Sun代碼? – bgroenks

+0

@ ghostsoldier23你的意思是「Java庫代碼不會導致所有acc檢查失敗?」?它全部擁有所有權限。一般來說,庫代碼至少需要權限作爲使用它的應用程序。通常,這意味着該庫具有所有權限,或者將其與應用程序的權限綁定在一起。 –

+0

你是說AppContext是com.sun。*庫的一部分嗎? 「禁止」,「你不能通過」圖書館? ; D – bgroenks

1

SecurityManager是一個可怕的混亂。您應該考慮要求將插件寫入Java的一個子集中,以便您可以對其可以執行的操作進行合理的推理,而不是反覆授予更多可濫用的權限。

Joe-E提供可分解的安全性。From http://lambda-the-ultimate.org/node/3830

我們介紹Joe-E,這是一種旨在支持安全軟件系統開發的語言。 Joe-E是Java的一個子集,可以更輕鬆地構建和實現具有強大安全屬性的程序,這些屬性可以在安全審查期間檢查。它使程序員能夠將最小特權原則應用於他們的程序;實現無法繞過的特定於應用程序的參考監視器;引入和使用領域特定的安全抽象; 安全地執行並與不可信代碼交互;並建立安全,可擴展的系統。 Joe-E演示瞭如何在保留主流面嚮對象語言的特性和感覺的同時實現對象能力語言的強大安全屬性...

+0

我相信Joe-E目前只能用於Java源代碼,而不是Java字節碼。所以你必須分配插件作爲源。我不完全確定Joe-E的狀態。但是,非常粗略地說,Java2應該如何完成。 –

+1

@ TomHawtin-tackline,我相信你是對的。 [** 6 Implementation **](http://www.cs.berkeley.edu/~daw/papers/joe-e-ndss10.pdf)說:「我們對Java源代碼執行檢查,而不是在Java類上執行 因爲Java運行時將字節碼 僅限於有限的一組驗證檢查,允許字節碼 執行Java程序不能執行的一些操作。「這使他們可以訪問像內部類特權這樣的語言小說,並讓他們忽略圍繞受保護區域的主要字節碼重構,並讓他們跳過關於「javac」不太可能產生的字節碼的推理。 –