JNLP：在簽名代碼中加載未簽名代碼

我們在通過Java webstart的混合代碼錯誤時遇到困難。總之，我們有我們的主要JNLP文件，我們已經簽署了它直接加載的所有代碼。我們已將全部權限選項添加到主JNLP。它加載的主類也來自簽名的jar。JNLP：在簽名代碼中加載未簽名代碼

當主類開始時，它引發了一些需要加載一些從JNLP B中取出的未簽名資源的東西。沒有任何JNLP B的資源被簽名，並且它們不需要任何特殊權限。

所有已簽名的代碼都是基於Oracle的混合代碼文檔進行設置的，並且在簽名之前已經將jar文件的清單設置爲「Trusted-Library：true」。

當未簽名代碼試圖通過簽名代碼，我們得到一個類未找到錯誤，像這樣被加載：

java.lang.reflect.InvocationTargetException 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
at java.lang.reflect.Method.invoke(Unknown Source) 
at com.sun.javaws.Launcher.executeApplication(Unknown Source) 
at com.sun.javaws.Launcher.executeMainClass(Unknown Source) 
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) 
at com.sun.javaws.Launcher.run(Unknown Source) 
at java.lang.Thread.run(Unknown Source) 

    Caused by: java.lang.NoClassDefFoundError: org/some/external/package/that/is/not/signed 
at org.our.signed.package.main(Main.java:87) 
... 9 more 

    Caused by: java.lang.ClassNotFoundException: org.some.external.package.that.is.not.signed 
at java.net.URLClassLoader$1.run(Unknown Source) 
at java.security.AccessController.doPrivileged(Native Method) 
at java.net.URLClassLoader.findClass(Unknown Source) 
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source) 
at java.lang.ClassLoader.loadClass(Unknown Source) 
at java.lang.ClassLoader.loadClass(Unknown Source) 
... 10 more

這裏是在JNLP的場景：

JNLP答：（總結）

<jnlp spec="1.5+" codebase="...." href="......"> 
    <information> 
    ...etc 
    </information> 
    <security> 
    <all-permissions/> 
    </security> 
    <resources> 
     <j2se version="1.6+" initial-heap-size="80m" max-heap-size="256m" href="http://java.sun.com/products/autodl/j2se"/> 
     <jar href="signedJar_1.jar" download="eager" main="true"/> 
     <jar href="signedJar_2.jar" download="eager" main="false"/> 
     <extension name="unsigned_ext" href="unsigned.jnlp"/> 
    </resources> 
    <application-desc main-class="(FROM SIGNED CLASS in signedJar_1.jar)"/> 
</jnlp>

JNLP B（所述unsigned.jnlp裝載機）

<jnlp spec="1.5+" codebase="....." href="......"> 
    <information> 
    ...etc 
    </information> 
    <resources> 
    <jar href="unsigned.jar"/> 
    </resources> 
    <component-desc/> 
</jnlp>

我們已經注意到安全異常工作正常，因爲如果我們將未簽名的jar移動到具有所有權限並已簽名jar的JNLP中，我們就會得到預期的安全異常，即Java不會讓我們混合與Trusted-Library簽名的代碼：真實和未簽名的代碼，沒有清單屬性。

想法？類加載器無法從未簽名的代碼中找到java文件嗎？是否有什麼特別的東西讓我們錯過了允許簽名代碼運行未簽名的代碼？我只看到了人們遇到問題的情況，即獲取未簽名的代碼來運行已簽名的代碼，這是我能理解的。

來源

2012-04-19 rmmeans

可信庫加載器是（可能不可信的）小應用程序類加載器的父類（在類加載器委託的意義上）。把它看作是引導類加載器。所以不受信任的類可以鏈接到受信任的庫類，但反之亦然。不用擔心改變清單和使用WebStart，你可以試試這個東西，通過將-Xbootclasspath/a:和你的不可信任的類加入-classpath（這是該特性在實現之前被試用過）。

JNLPAppletLauncher是如何讓trusted-libraries調用applet代碼的一個例子。小程序類加載器可以通過Thread.currentThread().getContextClassLoader()獲得，這只是從那裏反思。編寫安全可信的庫代碼非常棘手。請記住，你不能相信不受信任的代碼。

來源

2012-04-19 21:46:59

所以你說可信的代碼根本不能運行不可信的代碼？例如，我們的應用程序是一個通過網絡啓動加載的內部CRM（無小程序）。我們的CRM有時需要訪問本地文件系統（簽署/全部燙髮的原因）。我們的客戶關係管理系統還需要一些其他的罐子，比如用於UI的swingx.jar，幫助設置如jhall.jar等。那麼我們的可信代碼就無法訪問這些其他罐子？我們是否必須將我們的可信任功能放入自己的罐子中，並僅簽署這些功能，讓我們的主要核心不受信任，以便我們還可以使用不可信的罐子？ – rmmeans 2012-04-19 22:05:06

（Applet和JNLPWebStart應用程序/小應用程序基本上是可以互換的。）不可信賴的代碼依賴於不可信代碼的行爲。您可以將受信任的代碼作爲庫，但您需要非常小心，在其上執行的任何操作都是安全的。你不能只有一種方法，比如說，將某些數據保存到指定的文件名（並保持安全）。 – 2012-04-19 22:38:05

@ TomHawtin-tackline如果沙盒擴展中的代碼是數字簽名的，它會導致問題嗎？ – 2012-04-20 02:25:34

JNLP：在簽名代碼中加載未簽名代碼

回答

相關問題