It's not too late for access control

[Eric Johnson]

On 7/11/16 7:21 AM, David M. Lloyd wrote:
> The crux of this access control discussion is that, up until JDK 9, 
> "public" meant "public".  End of story.  If you did not want something 
> to be visible, you made it not public.  Very simple and very clear.  
> The word "public" literally means "accessible to all" after all; 
> that's why the term was selected in the first place, and it is nearly 
> certain that this was the intent of the thing up to this date.
To be fair, OSGi established a precedent - a "bundle" can make a 
distinction between that which is public and that which is "exported". 
(I think of this as the distinction between public vs. published, 
because I like the alliteration).

Mostly, I agree with your point, though! OSGi makes this distinction, 
because it is worried about having multiple versions of the same package 
available at run-time, and even that bundle A can have a complete copy 
of JAR B - from a completely different project - and not want to take 
responsibility for the "public" version of the API of JAR B. So OSGi 
explicitly needs to be able to hide ostensibly public APIs, because 
author A cannot possibly correctly guess the intent of author B in all 
cases. However, Jigsaw is explicitly not concerned about this problem, 
so the extra distinction seems spurious to me.
>
> What is being required in the JPMS spec, and, I dare to suggest, what 
> has been generally asked for by the public (and even required by the 
> JDK), is a way to provide an additional capability - the ability to 
> selectively share otherwise unshared code.
>
> The existing Java language accessibility model is (of course) 
> well-understood by experts.  For new developers, the concepts takes a 
> bit of time to explain but can generally be grasped.  In the end the 
> accessibility of a member is generally easily determined by examining 
> the qualifiers of that member.
>
> What has been proposed and implemented in Jigsaw is essentially a 
> completely new approach to access checking.  Because it is new, and 
> because it is essentially untried, I predicted that issues would arise 
> not unlike the ones being currently discussed.  I argue that this 
> approach is not optimal, for at least reasons discussed on this list 
> and in this email, but that even now, it's not too late to change the 
> approach.
What infuriates me is that in all this discussion, I don't see anyone 
talking about a threat analysis. What are we trying to protect, from 
whom, and why? I see comments about how implementation details of the 
JRE (such as "com.sun" packages) must be hidden, but without reference 
to the threats that cause a problem.

I've seen enough security issues about Java to believe that there /are/ 
threats that Oracle should be concerned about. And I'm happy to have 
Oracle hide ostensibly public classes in the JRE at runtime, because I 
want the JRE to have a smaller attack surface.

At compile time, project Jigsaw makes total sense to me. A modularized 
Java makes sense, both because it highlights an excessive dependency 
tree, and because it can help reduce the footprint of the code. In other 
words, it isn't a security measure, it is a design tool. At runtime, 
though, does the JVM benefit from something more complex than a simply 
layering model? Layer 0 - the boot system, Layer 1 - the JRE, Layer 2-N 
- defined by the developer. I'm guessing in the server model, Layer 2 is 
the "container" (Servlet, Spring, etc.), and Layer 3 is the "application".

However, I'm unable to assess whether my proposed JVM model meets the 
security requirements. Why? Because I've never seen the threat analysis 
spelled out or referred to on this list. Maybe such a document exists?
With the simple layered model, almost all applications (except those 
that load JRE internal details either via reflection or direct linking) 
would continue to work as is. With the Jigsaw model, I feel like I have 
to assume everything will break, unless otherwise fixed.

Hoping something about this will change.

> I propose, once again, that rather than changing the meaning of 
> "public" to something unintuitive (and indeed counter to the 
> definition of the actual word), we instead allow the selective 
> extension of package-private.  Users would make public any type or 
> member which is *meant* to be public, i.e. accessible by all. Rather 
> than (at best) changing their expectations as to the behavior of 
> "public" only to immediately betray that expectation by forcing them 
> through a backdoor in order to meet practical needs, we ensure that 
> their expectations remain: public members are public, and things that 
> are secret are not public.
I think this is an interesting idea to consider. Except again, I'm 
unclear on what we're trying to protect from whom, and why? So I don't 
know if this solves the problem.

Eric