Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[Eric Johnson]

On 9/25/16 8:50 PM, GREGG WONDERLY wrote:
> I still, like others seem to, find it amazingly odd, that the security manager, existing basis for access control is not still what would count.
I'm with you there. I'm fascinated that this thread has triggered 
references to the "legacy" security manager. Somehow, the security 
manager is defacto not worth extending / expanding, but this whole 
module boundary enforcement scheme is.
>    I understand that the JDK itself is not deployed with a security manager impl in most cases, and thus there would be no access context for the security manager to be used against.
A different way of framing this whole discussion, though, is to say that 
with Jigsaw, Java always runs with some kind of "security manager". 
Oracle may not want to call it that (whatever, it is just a name), but 
that's effectively what it is. What is annoying / odd / frustrating is 
that there's no variability in implementation. The discussion on this 
list has made it crystal clear that the JSR authors did not fully 
anticipate the range of security people would need to impose. Using an 
analogy, even SELinux has configurations where boundary violations are 
merely logged, not blocked.

>    What’s odd, is that you are still trying to block access to reflective access to the “open JDK”.  If it’s really open and it’s really something that the community contributes to, why do we need to block access, hide details and otherwise obfuscate access details?  Modularization should just be about separating pieces not needed should it not?
Well, yes and no. I'm all for modularizing the JDK. Yet, for effective 
modularization, you have to hide things at compile time. The treatment 
of com.sun.* APIs over the years is clear indication that merely 
flagging these issues as warnings will not keep people from poking 
around the innards. The details need to be blocked, or people will keep 
using (exploiting?) them.
>    Why has this degenerated into such a huge bit of access restriction too?
Runtime enforcement is another problem. I respect Oracle's (implicit) 
position that they need to block access to the "non-published" aspects 
of the JDK. Why? Because every API they can hide reduces the attack 
surface for every application that runs in the ecosystem. By in large, 
that's entirely a good thing. My company's products have in the past 
been exposed to this very problem - reflective access to the innards of 
the JDK enabled possible attacks - /merely by the presence of the wrong 
version of a JAR file in the classpath/. If the JDK innards were hidden 
at the time, the attack avenue would have been blocked.

Taking enforcement further, though, becomes problematic very quickly. I 
suspect the best way to inform that discussion would be with well 
explored threat models. That way, we'd know what the new module 
boundaries are supposed to be protecting us from. With the current 
Jigsaw approach, it seems logical that if it is good for the JDK to 
reduce its attack surface, that it is likely a good thing for everything 
that runs on top of the JDK. However, that's making all sorts of 
assumptions about threats. So what we seem to be left with on this 
mailing list is continued exploration of use-cases that run afoul of the 
"reduce attack surfaces for everything" approach. Whereas I think we'd 
all benefit from looking at the different threat models.
> Could people who think that modularity should solve these problems and the security manager not be part of the solution please provide some details about how security is the modularization mechanisms responsibility and not the security managers?  For deployment, I’ve always used the security manager to limit/control access when I take some 3rd party code/jar and deploy it into a production environment.  That helps me restrict its access to resources in a manageable and maintainable way.
>
> What I see happening, is that this single issue of “access” to pieces of software, from other pieces of software is degenerating into huge amounts of complexity and specification and release control, which isn’t really what makes “open software” work together.
I think the "open software" aspect is likely unimportant. Huge amounts 
of complexity and specification are an anti-pattern in any environment. 
Particularly in the realm of any kind of security enforcement, the 
simpler the better. The more complex the rules, the more likely it is 
that the implementation makes a mistake.

Eric.