Re: JDK9 permission checks leaking outside of module boundaries

[Peter]

No, the module system prevents access.  They are redundant however, the jvm 
class libraries  access these packages, not river.

The need to grant these permissions conplicates security.  The jdk developers 
should first consider if the code that accesses these packages is privileged or 
not, if not then access it using only the domain of the acessing code as a do 
privileged call.  Otherwise if the calling code is already privileged, it may 
need to remain.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Patricia Shanahan 
Sent: 21/08/2016 09:35:04 pm
To: dev@river.apache.org
Subject: Re: JDK9 permission checks leaking outside of module boundaries

Do these grants create a security risk? 

On 8/21/2016 3:18 AM, Peter wrote: 
> 
> There are a number of permission checks leaking outside module 
> boundaries, because their classes call jvm library code that eventually 
> cause these permission checks. 
> 
> Is this correct? 
> 
> I've had to grant the following permissions in policy files, but the 
> classes involved are not accessing these packages directly: 
> 
> permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.util.logging.resources"; 
> permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.util"; 
> permission java.lang.RuntimePermission 
> "accessClassInPackage.jdk.internal.misc"; 
> permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.ssl"; 
> permission java.lang.RuntimePermission 
> "accessClassInPackage.sun.security.action"; 
> 
> See similar below: 
> 
>  [java] - 
>  [java] 
>  [java] Running 
> org/apache/river/test/spec/jeri/ssl/SslServerConstructorAccessor.td 
>  [java] Time is Sun Aug 21 20:00:16 AEST 2016 
>  [java] Starting test in separate process with command: 
>  [java] 'C:\Program Files\Java\jdk-9\bin\java' 
> -Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager 
> 
> 
>-Djava.security.policy=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/ssl.policy
> 
> 
> -cp 
> 
>C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jiniharness.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jinitests.jar;\mergedpolicyprovider.jar;\jsk-policy.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\jsk-platform.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\jsk-lib.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\high-scale-lib.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\custard-apple-1.0.3.jar
> 
> 
> -ea -esa -Dorg.apache.river.jsk.port=9080 
> -Dorg.apache.river.qa.port=9081 
> 
>-Dorg.apache.river.jsk.home=C:\Users\User\Documents\NetBeansProjects\River\trunk
> 
> 
> 
>-Dorg.apacheriver.qa..home=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa
> 
> 
> 
>-Dorg.apache.river.qa.harness.harnessJar=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jiniharness.jar
> 
> 
> 
>-Dorg.apache.river.qa.harness.testJar=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jinitests.jar
> 
> 
> -Dorg.apache.river.qa.harness.runjiniserver=false 
> -Dorg.apache.river.qa.harness.runkitserver=false 
> 
>-Djava.security.properties=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/harness/trust/dynamic-policy.properties
> 
> 
> -Dorg.apache.river.qa.harness.testhosts= 
> 
>-Djava.util.logging.config.file=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\src\org\apache\river\test\resources\qa1.logging
> 
> 
> -Djava.rmi.server.useCodebaseOnly=false 
> -Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true 
> 
>-Dorg.apache.river.test.home=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa
> 
> 
> -Dorg.apache.river.test.port=9082 
> 
>-Dorg.apache.river.qa.harness.policies=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/resources/jinitest.policy
> 
> 
> 
>-Djava.security.auth.login.config=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/ssl.login
> 
> 
> 
>-DkeyStoreURL=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/keystore
> 
> 
> 
>-DkeyStorePasswordURL=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/keystore.password
> 
> 
> org.apache.river.qa.harnessMasterTest 
> org/apache/river/test/spec/jeri/ssl/SslServerConstructorAccessor.td 
>  [java] 
>  [java] TIME: 8:00:20 PM 
>  [java] 
>  [java] MasterTest.doTest INFO: 
>  [java] == CALLING CONSTRUCT() 
> == 
>  [java] 
>  [java] MasterTest.doTest INFO: 
>  [java] === CALLING RUN() 
> 

Re: JDK9 permission checks leaking outside of module boundaries

[Patricia Shanahan]

Do these grants create a security risk?

On 8/21/2016 3:18 AM, Peter wrote:


There are a number of permission checks leaking outside module
boundaries, because their classes call jvm library code that eventually
cause these permission checks.

Is this correct?

I've had to grant the following permissions in policy files, but the
classes involved are not accessing these packages directly:

permission java.lang.RuntimePermission
"accessClassInPackage.sun.util.logging.resources";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util";
permission java.lang.RuntimePermission
"accessClassInPackage.jdk.internal.misc";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.ssl";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.action";

See similar below:

 [java] -
 [java]
 [java] Running
org/apache/river/test/spec/jeri/ssl/SslServerConstructorAccessor.td
 [java] Time is Sun Aug 21 20:00:16 AEST 2016
 [java] Starting test in separate process with command:
 [java] 'C:\Program Files\Java\jdk-9\bin\java'
-Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager

-Djava.security.policy=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/ssl.policy

-cp
C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jiniharness.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jinitests.jar;\mergedpolicyprovider.jar;\jsk-policy.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\jsk-platform.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\jsk-lib.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\high-scale-lib.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\custard-apple-1.0.3.jar

-ea -esa -Dorg.apache.river.jsk.port=9080
-Dorg.apache.river.qa.port=9081
-Dorg.apache.river.jsk.home=C:\Users\User\Documents\NetBeansProjects\River\trunk

-Dorg.apache.river.qa.home=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa

-Dorg.apache.river.qa.harness.harnessJar=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jiniharness.jar

-Dorg.apache.river.qa.harness.testJar=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jinitests.jar

-Dorg.apache.river.qa.harness.runjiniserver=false
-Dorg.apache.river.qa.harness.runkitserver=false
-Djava.security.properties=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/harness/trust/dynamic-policy.properties

-Dorg.apache.river.qa.harness.testhosts=
-Djava.util.logging.config.file=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\src\org\apache\river\test\resources\qa1.logging

-Djava.rmi.server.useCodebaseOnly=false
-Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true
-Dorg.apache.river.test.home=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa

-Dorg.apache.river.test.port=9082
-Dorg.apache.river.qa.harness.policies=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/resources/jinitest.policy

-Djava.security.auth.login.config=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/ssl.login

-DkeyStoreURL=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/keystore

-DkeyStorePasswordURL=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/keystore.password

org.apache.river.qa.harness.MasterTest
org/apache/river/test/spec/jeri/ssl/SslServerConstructorAccessor.td
 [java]
 [java] TIME: 8:00:20 PM
 [java]
 [java] MasterTest.doTest INFO:
 [java] == CALLING CONSTRUCT()
==
 [java]
 [java] MasterTest.doTest INFO:
 [java] === CALLING RUN()
===
 [java]
 [java] java.util.ServiceConfigurationError:
javax.security.auth.spi.LoginModule: Provider
com.sun.security.auth.module.KeyStoreLoginModule could not be instantiated
 [java] at
java.util.ServiceLoader.fail(java.base@9-ea/ServiceLoader.java:379)
 [java] at
java.util.ServiceLoader.access$800(java.base@9-ea/ServiceLoader.java:218)
 [java] at
java.util.ServiceLoader$ModuleServicesIterator.nextService(java.base@9-ea/ServiceLoader.java:741)

 [java] at
java.util.ServiceLoader$RestrictedIterator$2.run(java.base@9-ea/ServiceLoader.java:541)

 [java] at
java.security.AccessController.doPrivileged(java.base@9-ea/Native Method)
 [java] at
java.util.ServiceLoader$RestrictedIterator.next(java.base@9-ea/ServiceLoader.java:543)

 [java] at
java.util.ServiceLoader$2.next(java.base@9-ea/ServiceLoader.java:921)
 [java] at