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.
