Input validation of serialized data
Interesting link: http://openjdk.java.net/jeps/290
Re: JDK9 permission checks leaking outside of module boundaries
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
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 javax.security.auth.login.LoginContext.invoke(java.base@9-ea
JDK9 permission checks leaking outside of module boundaries
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 javax.security.auth.login.LoginContext.invoke(java.base@9-ea/LoginContext.java:690) [java] at javax.security.auth.login.LoginContext.access$000(j