SecurityManager environments

[Gregg Wonderly]

> On Apr 5, 2017, at 12:53 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 05/04/2017 16:26, Gregg Wonderly wrote:
>> :
>> 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.
> You are right that the performance overhead when running with a security manager can be a problem. Walking the stack to get the intersection of the permissions has historically been a big part of this. If there are proposals and patches to improve the performance then security-dev is the place to bring those for discussion, maybe hotspot-dev if it gets into the stack walking in the VM.

I believe that these are places where Peter has taken some of his findings.

>> 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?
> I assume the breakage you see is just a consequence of strong encapsulation. There is a lot of existing code that relies on being able to break into non-public members or access protected members from the wrong context. These are issues that should be reported to the owners of these libraries.  We know it will be difficult in the interim before the maintainers release new versions that work with JDK 9.
> 
> You mention Spring. There are some very smart people working on it and tracking JDK 9 closely from what I can tell. Existing versions SpringBoot  fail today for a couple of reasons - one is that it is helping itself to a non-public constructor for MethodHandles.Lookup. Another is that it wants to invoke the protected ClassLoader.defineClass from the wrong context. I'm confident that they will fix this code in time as there new APIs to address these use cases.  In the mean-time then there are command line options to keep existing versions working. Yes, command line options are pain but for executable JAR cases like this then there are JAR file attributes that come some relief from CLI options.

I believe that the focus is still on just the server class of applications.  Desktop applications started from a double clicked jar file, have no explicit access to the command line.  It just doesn’t exist for that application.  It only exists for “all” applications (launched for mime-type mapped application mappings) in most cases (linux/unix shortcuts can be constructed to specify arguments more readily, but still require expertise to do that).

> As regards the security manager then it's hard to see how it fits into the discussion. To be honest, we don't see a lot of security manager usage on the server side these days.

This is one of my standing issues.  The focus is all around server applications.  Those are the applications where there is engineering and development around deployment.  Desktop is completely different the JRE/JDK is update asynchronously from the actual application.   There are all kinds of places where Java gets used besides a “engineered” deployment.  It’s those environments where corporate standards for security are going to require updates to occur in corporate environments, or whatever update policy is decided on by Oracle for the desktop JRE environment to recommend to the user that they update there JDK/JRE release to the most recent.  If they just have a clickable jar which has been carefully crafted and packaged to hold some of the broken code from other libraries, who is going to help those users recover to a working application?  Who’s going to pay for all of the support people who have to hold peoples hands to get stuff fixed?

Yes, there might be an organization inside of a corporation who is going to analyze things and figure out what’s broken.  They are going to then need to find the fixes, test them, engineer a deployment scheme and spend real time and money to take care of the details.  What timeline constraints are going to impact them?  Some new applications will be deployed with new command line arguments that old JDKs don’t support.  Some old applications are going to break because they have old versions of Spring in them.  How will a user with a single default version of Java installed, be able to manage the fact that they have apps that need JDK-9 command line support and others that can’t use JDK-9 because of the new requirements for command line arguments to work around the broken software they have been using?

People have multiple Java applications in use, and probably a sizable number of those are not going to be broken.  But, the Spring libraries seem to have become quite prevalent in lots of places and that, for me, is going to be the stick in the mud that just keeps on getting stuck.

> I look at a lot of bug reports and error logs that include the command line and I don't see -Djava.security.manager very often. If the overhead was zero and it was easier to identify the permissions needed by each component then maybe it would have got more popular. Another reason is that the access checks that you see in the discussions here are the access checks that the JLS and JVMS specifies. They are access checks that have to be done when you are not running with a security manager. They are also at a completely different level, meaning can bytecode in C1.m can access a member of C2. This is very different to the stack based permission checks that a security manager does.

Yes, all of these JVM level access checks are where they need to be.  There are a lot of details of the actual implementation which I am sure I do no understand.  However, I’ve been around Java for a long time.  I create a broker for Java before there was JMS or JXTA and lots of other things that happened 20 years ago.  It’s still a vital platform for me, because I still hope we can get something to keep from creating yet another procedural language that just keeps on denying the opportunity for large scale integration of software systems which should be in the same process.

Gregg