It's not too late for access control

[Eric Johnson]

At least someone replied to my question.

On 7/14/16 5:44 AM, Russell Gold wrote:
>> On Jul 12, 2016, at 1:31 PM, Eric Johnson <eric at tibco.com> wrote:
>>
>> 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.
> It’s primarily a maintenance issue, IMO. It is common that we provide classes and methods that are intended to be used from elsewhere inside a product, but which we do not want users to see. That is, it is much the same as the reason you use “private” for class internals - if everything is publicly accessible, people use it, and you cannot refactor your code without breaking theirs.
If the entire aim is just a maintenance issue, then I assert that 
compiler changes should be sufficient. At that point, anyone who fires 
up runtime reflection to work around the compiler gets the benefits and 
the costs that they deserve. Benefits include the ability to leverage 
code in the guts of any library or the JRE that the authors decided they 
didn't want to publish. And they embrace the likelihood that it will 
break in the future.

I don't feel a huge need to argue about language design. Other people 
can battle over the contentious issues of what is appropriate for 
language constructs. That could be module boundaries with metadata, it 
could be new keywords like "friend", or even package level declarations 
(more like OSGi). I suspect we'll all adopt to the "best" solution 
determined by those who want to improve the language.

To make this more concrete, Scala could introduce some kind of scoping 
mechanism completely unfamiliar to existing Java developers. Few people, 
if any, would be upset that it was merely a compile-time enforcement, 
and the runtime didn't enforce the new capability. Same should be true 
of Java itself. For one possible framing, perhaps I ought to be able to 
compile a module-based application and yet run it on Java 8 without 
modification?

So yes, modules for the compiler, if that's what Oracle thinks is best 
for the language, I can live with it. Need not affect the runtime, though!

However, like I said in my original email, I believe genuine security 
issues can be found in this quicksand. The JRE has valid reasons to 
prevent access to implementation details. That reduces the possible 
attack footprint, and also strengthens the walls of the "sandbox" that 
Java puts up (more code to tunnel through before getting to the 
vulnerable chunk). And it seems pretty clear, from the CVEs found 
<https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html> 
in the JRE, that these changes should happen regardless of whether or 
not the runtime has a security manager installed, because it is common 
enough to run without one. To pick an example from another language, you 
can't run Ruby without having "taint" support on.

In other words, the Jigsaw runtime change to enforce module boundaries 
amounts to /always/ running with some sort of security manager. If you 
frame the implementation that way, though, then it is clear that 
alternate implementations might be quite valuable - especially in a 
transition phase from prior versions of Java.

While this discussion is ostensibly about reflection and accessibility, 
I'm viewing it as really about what kind of security manager is the 
minimum allowed at runtime.

I applaud Oracle's effort to tackle the unpleasant task of imposing (on 
us) a mandatory minimum security monitor on the JRE classes. However, to 
date, Jigsaw is imposing one specific model of mandatory minimum 
security on all of us, without entertaining alternate solutions. That's 
what I find enormously frustrating. It is pretty clear to me from the 
discussions on this mailing list that the one they've enforced so far is 
the wrong one, at least if Java 9 is going to be adopted widely.