Unnamed module and duplicate package

[Mandy Chung]

> On Mar 14, 2016, at 12:27 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 3/12/16 9:57 AM, Alan Bateman wrote:
>> 
>> On 11/03/2016 15:30, David M. Lloyd wrote:
>>> 
>>> What are the limiting factors?  In my analysis the only problem that
>>> seemed close to insurmountable was the special natives that are used
>>> in the JDK but these only seem to be used from java.base.  Does it all
>>> boil down to getClassLoader()==null security checks on the Java side,
>>> or is there a JVM component that I haven't discovered?
>> I have no doubt that it would be a big effort.
>> 
>> One of the most difficult issues when de-privileging is identifying the
>> minimum permissions. It gets complicated in areas with callbacks where
>> intermediate frames reduce the effective permissions. For several of
>> these modules then it may be that they end up needing AllPermission so
>> the benefits of moving them out are significantly reduced.
>> 
>> Related is performance when running with a security manager. A long
>> standing optimization is that code in the boot loader has AllPermission.
>> 
>> At things stand then we can't move any modules that export java.* APIs.
>> If getPlatformClassLoader() and the related spec change to allow java.*
>> classes be loaded by the platform class loader and its ancestors goes in
>> then it removes this hurdle.
>> 
>> I'm sure there will be lots of other issues once you get into it. Some
>> of the modules (like java.management) are tightly coupled to the VM. On
>> getClassLoader() returning null then such uses would need to be
>> examined. I don't expect there are too many as we replaced a lot of them
>> in the JDK 8 time frame as part of JEP 162.
> 
> So really there are multiple parts to be able to move modules out of the bootstrap class loader:
> 
> 1. Relax the spec so that other class loaders (preferably only trusted/blessed class loaders) can define java.* classes
> 

This is only needed for modules defining java.* types.

> 2. Come up with a replacement for getClassLoader() == null checks (e.g. getClassLoader() == null || getClassLoader().isPrivileged())
> 

We had attempted to clean up JDK code in JDK 8 and added jdk.internal.VM.isSystemDomainLoader(ClassLoader).

This is not that hard to identify.

Once it’s moved to be defined by the platform class loader, caller’s sensitive operations may require permission (e.g. methods that does security check based on the caller’s class loader).  The bootstrap class loader is also the root class loader which has access to all types defined by its child class loader.  But that may not be true once it’s deprivileged.  We need to identify those caller-sensitive operations and wrap with doPrivileged if missing.

Also class resolution does a package-access check using the initiating class' protection domain.  This is extremely hard to diagnose.  The diagnosability of that area is really bugging me that really needs to be improved.

Not to mention when native code is involved but modularization is not cleaned.

 
> 3. Then go back and incrementally deprivilege as many modules as possible/practical, as time permits
> 

There is no good existing tool to help analysis.  It heavily depends how well the existing test coverage is to run with security manager. Minimum set of permissions is the first step.  As Alan mentions, test, performance, compatibility and many other things to be thought through.

> However the benefits seem attractive: improved security (even if only one module gets deprivileged), ability for core modules to depend on upgradable modules (java.sql case).
> 

“core modules” - I assume you refer to the modules defined by the boot module.  I don’t see why they need to depend on the upgradeable modules and don’t see any benefit.

> As far as allowing other class loaders to load java.* classes - could it not just be a matter of setting a flag on ClassLoader which is only settable by a non-public constructor or something like that?  

I don’t follow your suggestion on a flag.

java.* types currently is restricted to be defined by the bootstrap class loader.  The spec change is necessary to allow future deprivileging work to take place.


> The flag could be checked easily by Java or native code, and it doesn't tie the JDK more tightly to specific hierarchical class loading arrangements.


What defining class loader of java.* type is unrelated to the class loader hierarchy.

Mandy