Disallowing the dynamic loading of agents by default

[Gregg Wonderly]

> On Apr 4, 2017, at 10:45 AM, Andrew Dinn <adinn at redhat.com> wrote:
> 
> On 04/04/17 15:58, Gregg Wonderly wrote:
>> Alan said:
>> 
>>> The issue here is nothing to do with the security manager, assume
>>> no security manager in the picture.
>> 
>> But, I always have a security manager in the picture.  It’s how I
>> always grant access to various pieces of the JDK features to my
>> application.  It’s how I limit/grant access to the details that I
>> care about my users being exposed to by using my software.  So,
>> saying that a SecurityManager doesn’t matter, when this is clearly a
>> JVM security issue, just doesn’t fly for me.   As I’ve already said,
>> a command line argument can feel like a permission, but it is like
>> AllPermission.  It doesn’t help me manage what I am opening my users
>> to.  If I have to use the AllPermission for my users to deploy, and
>> they are on a network, I’ve now opened them up to network penetration
>> by other agents!  That’s absolutely not acceptable to me.
> 
> That may be so but, as Alan said, there are many other Java users who
> have never had a security manager in the picture. You seem to be
> assuming that we can rely on users to correct that omission as an
> element of how we address this problem. I'd suggest that is just as
> questionable  -- indeed, probably more so  -- as assuming that we can
> rely on users to remember to reset the current proposed default to
> enable dynamic agents.

Let me put together my whole argument again.

1) People can edit jar files and completely obliterate any security settings expressed in those files.
2) People can add JNI modules and have complete access to all details of the JVM environment.
3) People can recompile the openJDK JVM to turn off anything that they want about this development.
4) People are going to have to use command line switches to control this behavior in environments where their current applications are broken by Jigsaw changes.

So, in the end, integrity, modularity and ultimately the goals of this project can only be maintained by active participation from the community of developers which we hope will all be capable, and able to participate because their use of the JVM (for other JVM languages besides Java) can deal with these changes.

This whole effort relies on developers to make it possible for users of java to succeed at using JDK-9.  If developers don’t do that, or can’t do that because of limitations of JigSaw, this will be like windows-7 users.  There will be a lot of old cruft setting around giving Java a bad name because it won’t be current and the new version of Java broke it.

I am not trying to be a arse about this.  I am being forthright and direct with my comments and recommendations because I believe that’s the best way to not beat around the bush.

> Please try to assume that Alan might be arguing for a more nuanced
> position than the one you assumed when his argument appears to be making
> no sense to you. He is neither stupid nor ignorant of what a security
> manager can and cannot do. If anything he says leads you to question
> dconfirming such an opinion before posting it.

I am not one to assume anything.  That’s a big fault of failing discussions.  Everything needs to be on the table here.  What’s important to me, is important to me.  What’s important to another group of developers, is important to them.  What is not helping me be comfortable with this, is the simple fact that nothing done here, guarantees anything without developers participating “nicely”.

At the forefront of the failure of the SecurityManager to be an avidly used element of Java applications, is the simple fact that the whole infrastructure is horribly inefficient and full of locks and mutable data which should not be locked and should instead be immutable.  But, because “assume no security manager in the picture” is the state of “the world”, the details have not been fixed, officially.  In the Jini community, Peter Firmstone (most of the recent work), and I, have spent quite a bit of time on understand and fixing these issues.  He has tried to push the knowledge of what needs to be done into various places, which I don’t recall at the moment.

In the end because JDK-9 breaks everything (well not quite, but nearly, since spring and other similar libraries are broken), requiring command line arguments, why not just finally fix Java by instituting a default SecurityManager, instead of the command line flags, which enforces all of these things.  Why not just require the added command line argument to be the permissions file to use?   It seems just insane, to me, for all of this infrastructure to exist, which does exactly what all of these command line arguments are going to essentially do (turn the permission to do something on/off) and then to just summarily go around it and completely ignore it.

I don’t know how else to say anything here more constructively without continuously pointing at the fact that I think this just completely BOTCHES the JVM with nonsense changes trying to recreate SecurityManager features, which already exist.  That’s where my “Do you know what the SecurityManager does?” argument comes from.  I just cannot look past this work and say, oh, yeah, lets put in some other form of “key” to the kingdom so that developers and users of Java have yet another way to do exactly the same “mechanisms” that we already have.   

It make absolutely no sense to me.

And I am being harsh and direct to invite comments and explanations and arguments about the pros of what is being done, not to try and shut people up because they think I just want to whine and fuss about this.

Gregg


> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander