SecurityManager environments

[Reto Merz]

>> To be honest, we don't see a lot of security manager
>> usage on the server side these days.

I'm really surprised about that. How can a app server or servlet container
like JBoss Tomcat etc guarantee that System.exit does not shut down the JVM?


>> 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.

Our app server (closed-source) set it via System.setSecurityManager while bootstrapping.
We have started using a SecurityManager over 11 years ago, basically to disallow invocation of
    System.setSecurityManager, System.setProperties
    System.exit, System.setIn, System.setOut
    Authenticator.setDefault, ProxySelector.setDefault
    HttpsURLConnection.setDefaultSSLSocketFactory
    HttpsURLConnection.setDefaultHostnameVerifier
    etc

We also disallow System.setProperty with these keys
    ssl.* 
    javax.net.ssl.*
    java.security.*
    http.proxyHost, http.proxyPort
    sun.util.spi.XmlPropertiesProvider

and all keys which are set at the time when we register our security manager (eg: "user.dir" etc).
At this moment we also set a custom java.util.Properties implementation via System.setProperties
so that access via System.getProperties() is restricted too, eg:
    System.getProperties().clear() // removes mutable entries only
    System.getProperties().put("http.proxyPort", "unlucky") // will cause a security exception

Of course there are still holes but in our case we just want to find erroneous code
from new programmer colleague which is still a little green.

Regards
Reto




 Von:   Alan Bateman <Alan.Bateman at oracle.com> 
 An:   Gregg Wonderly <greggwon at cox.net> 
 Kopie:   <jigsaw-dev at openjdk.java.net> 
 Gesendet:   05.04.2017 19:53 
 Betreff:   Re: SecurityManager environments 

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. 
 
> 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. 
 
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. 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. 
 
-Alan