JDK-8140470 : javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java test failed with AccessControlException
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: x86_64
  • Submitted: 2015-10-26
  • Updated: 2019-01-14
  • Resolved: 2015-12-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9
7u201Fixed 8u192Fixed 9 b99Fixed
Related Reports
Relates :  
JDK-8133151 - Preferred provider configuration for JCE
Description
The test fails with the following exception:

java.lang.Exception: XMLDSigWithSecMgr FAILED
	at XMLDSigWithSecMgr.<init>(XMLDSigWithSecMgr.java:153)
	at XMLDSigWithSecMgr.main(XMLDSigWithSecMgr.java:159)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:520)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
	at java.lang.Thread.run(Thread.java:747)
Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:468)
	at java.security.AccessController.checkPermission(AccessController.java:894)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:541)
	at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1497)
	at java.lang.ClassLoader$1.run(ClassLoader.java:501)
	at java.lang.ClassLoader$1.run(ClassLoader.java:499)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:499)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:759)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:152)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:470)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:76)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:371)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:365)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:364)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at sun.security.pkcs11.SunPKCS11$P11Service.isLocalKey(SunPKCS11.java:1126)
	at sun.security.pkcs11.SunPKCS11$P11Service.supportsParameter(SunPKCS11.java:1081)
	at java.security.Signature$Delegate.chooseProvider(Signature.java:1119)
	at java.security.Signature$Delegate.engineInitSign(Signature.java:1192)
	at java.security.Signature.initSign(Signature.java:535)
	at org.jcp.xml.dsig.internal.dom.DOMSignatureMethod.sign(DOMSignatureMethod.java:256)
	at org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:398)
	at XMLDSigWithSecMgr.<init>(XMLDSigWithSecMgr.java:138)
	... 7 more
Comments
Code review: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013159.html
03-12-2015
When I was updating tests in sun/security/pkcs11 to run with a security manager, I noticed that adding doPrivileged() blocks in SunPKCS11 class doesn't solve the problem of access to "sun.security.util" package. When I ran the XML test with "-Djava.security.debug=access:failure" option, I noticed that ACE is thrown doPrivileged() block at java.lang.ClassLoader.checkPackageAccess ... access: access denied ("java.lang.RuntimePermission" "accessClassInPackage.sun.security.util") java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1336) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:458) at java.security.AccessController.checkPermission(AccessController.java:894) at java.lang.SecurityManager.checkPermission(SecurityManager.java:541) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1497) at java.lang.ClassLoader$1.run(ClassLoader.java:501) at java.lang.ClassLoader$1.run(ClassLoader.java:499) at java.security.AccessController.doPrivileged(Native Method) at java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:499) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:759) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:152) at java.net.URLClassLoader.defineClass(URLClassLoader.java:470) at java.net.URLClassLoader.access$100(URLClassLoader.java:76) at java.net.URLClassLoader$1.run(URLClassLoader.java:371) at java.net.URLClassLoader$1.run(URLClassLoader.java:365) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:364) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) at sun.security.pkcs11.SunPKCS11$P11Service.isLocalKey(SunPKCS11.java:1126) at sun.security.pkcs11.SunPKCS11$P11Service.supportsParameter(SunPKCS11.java:1081) at java.security.Signature$Delegate.chooseProvider(Signature.java:1119) at java.security.Signature$Delegate.engineInitSign(Signature.java:1192) at java.security.Signature.initSign(Signature.java:535) at org.jcp.xml.dsig.internal.dom.DOMSignatureMethod.sign(DOMSignatureMethod.java:256) at org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:398) at XMLDSigWithSecMgr.<init>(XMLDSigWithSecMgr.java:138) at XMLDSigWithSecMgr.main(XMLDSigWithSecMgr.java:159) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:520) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) at java.lang.Thread.run(Thread.java:747) access: access allowed ("java.security.SecurityPermission" "getPolicy") access: domain that failed ProtectionDomain (jrt:/jdk.crypto.pkcs11 <no signer certificates>) sun.misc.Launcher$ExtClassLoader@3d6c1e6c <no principals> java.security.Permissions@5116dcb0 ( ("java.net.SocketPermission" "localhost" "connect,accept,resolve") ("java.io.FilePermission" "/scratch/asmotrak/jdk1.9.0b89/-" "read") ) ... http://hg.openjdk.java.net/jdk9/dev/jdk/file/600834e2e9c1/src/java.base/share/classes/java/lang/ClassLoader.java#l499 It happens because "jdk.crypto.pkcs11" module doesn't have an "accessClassInPackage.sun.security.util" runtime permission because the test overrides system policy: http://hg.openjdk.java.net/jdk9/dev/jdk/file/600834e2e9c1/test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java#l116 ... Policy.setPolicy (Policy.getInstance("JavaPolicy", new URIParameter(policyURI))); ... By default, "jdk.crypto.pkcs11" module is granted this permission: http://hg.openjdk.java.net/jdk9/dev/jdk/file/600834e2e9c1/src/java.base/share/conf/security/java.policy#l55 ... grant codeBase "jrt:/jdk.crypto.pkcs11" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.*"; ... Sorry for noise, the test should be updated to extend the default security policy instead of override. See similar JDK-8043277 The test can use "@run main/othervm/java.security.policy" action, but sometimes it may be better to enable a security manager during test execution to avoid granting to many additional permissions if a test requires some setup. I tried to set "java.security.policy" just before enabling a security manager, and it seems to work fine: diff -r 600834e2e9c1 test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java --- a/test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java Wed Dec 02 21:32:40 2015 +0100 +++ b/test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java Thu Dec 03 01:08:56 2015 +0300 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2006, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2006, 2015, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -33,8 +33,6 @@ import java.net.*; import java.security.KeyPair; import java.security.KeyPairGenerator; -import java.security.Policy; -import java.security.URIParameter; import java.util.ArrayList; import java.util.Collections; import javax.xml.crypto.dsig.*; @@ -115,10 +113,8 @@ // the policy only grants this test SocketPermission to accept, resolve // and connect to localhost so that it can dereference 2nd reference - URI policyURI = - new File(System.getProperty("test.src", "."), "policy").toURI(); - Policy.setPolicy - (Policy.getInstance("JavaPolicy", new URIParameter(policyURI))); + System.setProperty("java.security.policy", + System.getProperty("test.src", ".") + File.separator + "policy"); System.setSecurityManager(new SecurityManager()); try { I filed a separate JDK-8144539 to update pkcs11 tests to run with a security manager.
02-12-2015
Yes, updating the test to run w/ SM is a very good idea. Thanks for taking care of this.
09-11-2015
Thanks for review, Valerie. Agreed about line 109. I'll take a look at Token. I am planning to update most of tests in sun/security/pkcs11 (for Signature, Cipher, MAC, etc) to make them run with both enabled and disabled security manager. It will increase coverage and can show which classes need doPrivileged blocks.
09-11-2015
The approach seems fine. Some minor nit: you don't need to explicitly specify the return type in between the <>, e.g. change on line 109 is not necessary. Actually, <> is preferred over <Class> if applicable. It seems that Token class also uses sun.security.jca.JCAUtil, and I wonder if additional doPriv block would be needed.
09-11-2015
This test started to fail with b89, it used to pass before. Furthermore, it fails only on Solaris x64 now. JDK-8133151 was integrated to b89 (Preferred provider configuration for JCE) which introduced a new "jdk.security.provider.preferred" security property. On Solaris x64 the property is "AES:SunJCE, RSA:SunRsaSign" which means that SunRsaSign provider will be used for RSA by default. I noticed that the test passes on Solaris x64 if the security property in empty. The test signs and validate XML document with enabled security manager. It sets a security manager at runtime before it starts signing: http://hg.openjdk.java.net/jdk9/dev/jdk/file/5afa5a406c20/test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java After some debugging, I found out the following: 1. The test fails during signing XML document because it tries to load "sun.security.pkcs11.P11Key" class: http://hg.openjdk.java.net/jdk9/dev/jdk/file/5afa5a406c20/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java#l1125 ... private boolean isLocalKey(Key key) { return (key instanceof P11Key) && (((P11Key)key).token == token); } ... Here "key" is instance of "sun.security.pkcs11.P11Key" class which implements "sun.security.util.Length" interface. That's why it needs "accessClassInPackage.sun.security.util" runtime permission. (SunPKCS11-Solaris provider is preferred on Solaris) 2. By default on Solaris x64 "jdk.security.provider.preferred" security property is set to "AES:SunJCE, RSA:SunRsaSign". The test generates RSA key at XMLDSigWithSecMgr.java:114: http://hg.openjdk.java.net/jdk9/dev/jdk/file/5afa5a406c20/test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java#l114 ... KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); KeyPair kp = kpg.genKeyPair(); ... Here it uses SunRsaSign provider because "jdk.security.provider.preferred" security property contains "RSA:SunRsaSign". But if we reset "jdk.security.provider.preferred" security property on Solaris x64, then KeyPairGenerator uses SunPKCS11-Solaris provider. KeyPairGenerator successfully loads "sun.security.pkcs11.P11Key" class because test has not set a security manager at XMLDSigWithSecMgr.java:114. As a result, signing XML document succeeds because "sun.security.pkcs11.P11Key" class has been successfully loaded. I think the test is correct (according to test description, it is expected that XML Signatures can be generated and validated with SecurityManager enabled and default policy). If documented public API is used, crypto operations probably should not require runtime permissions to access classes in "sun.*" packages. SunPKCS11 class can limited doPrivileged() methods, for example: http://cr.openjdk.java.net/~asmotrak/8140470/webrev.00/ This fix adds a doPrivileged() block to SunPKCS11.supportsParameter() method, and as a result, the test passes. I also modified sun/security/pkcs11/Signature/TestRSAKeyLength.java test to use a security manager. It failed with similar ACE because of no permission to access "sun.security.rsa" package. It may be better to update public method in SunPKCS11 class to use limited doPrivileged() methods in order to access packages in "sun.*". I am moving this bug to "pkcs11" sub-category since the problem doesn't seem to be in XML DSig API. I am not an expert in PKCS11, could anyone take a looks at the webrev above? If the approach is fine, I can update other methods in SunPKCS11 class accordingly. Other tests in sun/security/pkcs11 can be updated to use a security manager as well in order to check that it works fine.
03-11-2015
Offhand, it looks like an additional permission to access sun.security.util needs to be granted in the test/javax/xml/crypto/dsig/SecurityManager/policy file.
02-11-2015