JEP 200: The Modular JDK

[David M. Lloyd]

On 08/27/2014 04:04 PM, mark.reinhold at oracle.com wrote:
> 2014/8/27 1:13 -0700, david.lloyd at redhat.com:
>> ...
>>
>> I think this is the fundamental difference.  You think "deterrent".  I
>> think "expectation management".  People who *want* the functionality
>> will get it; it is a far more efficient expenditure of energy to let
>> them do it and just clearly manage expectations than to try to modify
>> behavior (which will just result in frustration for users).
>
> As Alan noted, the experience of those of us working on the JDK itself
> has been rather different.  We've warned against using internal APIs for
> years, but it's had little effect.  In the meantime all this cruft upon
> which people have come to depend has gradually grown into a significant
> maintenance burden.  It's time to cut the cord.
>
>>                                                               Adding
>> artificial barriers is counter-productive, and may even introduce
>> security risks as yet more JVM security mechanisms are added on top of
>> the existing stuff (a lesson that the constant CVE avalanche indicates
>> has not been fully learned yet, especially in the context of Java).
>
> We're trying to improve security, and we suspect we can do this in a
> reasonably straightforward way.  Enforcing module boundaries in the VM
> would be a big improvement over the existing means of protecting JDK
> internals (e.g., SecurityManager::checkPackageAccess), which are are
> brittle and error-prone.
>
>> ...
>>
>> I don't know about that.  We're talking, as always, about the concepts
>> of visibility as opposed to accessibility.  Until now, all discussion
>> has been in the context of visibility, which as I said (and MR agreed)
>> is easily subverted - but then MR said he intends to "enforce module
>> boundaries via access-control checks in the VM" which blurs the line
>> considerably.  So if we're now moving into accessibility territory
>> across class loaders, we're definitely and squarely overlapping with
>> AccessController and its related facilities - i.e. "does module X have
>> permission to import module Y?".
>
> The type of module-boundary access-control check we're thinking of would
> be an extension of what the JVM currently does during class, interface,
> field, and method resolution, per JVMS 5.4.4 [1].  It's the exact same
> mechanism that keeps private members private, and it's very difficult to
> subvert.  It has little (direct) relation to AccessController or any
> kind of security-permission check.

An intra-classloader or intra-module access level akin to package 
access, as previously described in the initial stages of Jigsaw, is 
easily understood since this is just another access protection flag in 
class files and is fairly easily accomplished.  However once you start 
allowing modules to specify what modules may import from it (by name, 
presumably), you're now forced to define the scope of the names you're 
assigning, and thereby implicitly increasing the user's need to maintain 
security and integrity not just within modules, but also between them. 
IMO this in turn will imply (even more strongly than before) a loading 
level that corresponds to the aggregation of modules within a general 
namespace, which can manage the loading of modules as well as the 
assignment of their "friends", similarly to how class loaders (and in 
the future, I expect, modules) are responsible for the security and 
integrity of loading the classes and resources that comprise it.

Am I far off the mark here?

I do believe that there is still a strong overlap between the functions 
of AccessController and this mechanism though, in any event (not that 
I'm a great fan of that mechanism in general).  But maybe the module 
mechanism can provide additional ways to improve it somehow, or perhaps 
even to replace it, eventually.


--
- DML