JDK-8055206 : Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-08-15
  • Updated: 2019-02-01
  • Resolved: 2017-01-19
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 10 JDK 9
10Fixed 9 b154Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8177396 :  
Description
With modules, we can automatically derive the list of restricted packages from the JDK module definitions, and restrict these packages by default instead of relying on the package.access and package.definition properties. This would avoid having to manually maintain these properties and make the behavior more consistent with the access controls of the module system.

The solution for this enhancement consists of 3 main parts:

1. Remove almost all of the current packages from the package.access and package.definition Security Properties. Two exceptions will remain: sun.misc and sun.reflect. These are internal packages that are currently exported by the jdk.unsupported module. They must remain on the package.access list since they contain unsafe APIs that can be used maliciously.
 
2. Loosen the definition of the SecurityManager::checkPackageAccess and checkPackageDefinition APIs to allow the list of restricted packages to be augmented by an implementation. Also, add a missing @throws NPE to the checkPackageDefinition API.
 
3. Change the implementation of the SecurityManager::checkPackageAccess and checkPackageDefinition methods to restrict the packages of all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. These packages will not be listed in the package.access and package.definition properties -- instead they are automatically determined at runtime by using new JDK 9 module APIs. The non-exported packages include all packages 
that are either not exported at all by its containing module or are exported in a qualified fashion by its containing module.
Comments
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fe9b621d7ae2 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/7f5f8b336432
19-01-2017

FC Extension Request Remaining Work: The implementation is complete. A public code review will be sent out next week and there may be a few iterations based on comments. Risk: The risk level is considered low-medium. The CCC provides more details on the risk. Justification: This will align the SecurityManager package access checking with the module system such that the same set of non-exported packages is restricted by default. This is important for security reasons, and will significantly reduce the amount of work required to audit and maintain the list of restricted packages going forward. Estimate: I expect code review and CCC approval to take about a week, so I am targeting a date of Wednesday, January 18.
06-01-2017

SecurityManager.checkPackageAccess takes a string and the check involves comparing the string name vs the restricted package list. For modules, all non-exported packages are available. I expect that the check with a given Class<?> will be quick i.e. Class.getModule().isExported(....); if not, it is a restricted package (at least it's for JDK classes). It needs to think through what it means to user-defined modules.
16-06-2015

See also JDK-8047813 where this is also proposed, maybe we should move this new issue to be a sub-task.
15-08-2014