[wildfly-dev] my 2 cents on Security Manager discussion

[Josef Cacek]

Hi Arjan,

let me give you few examples. Do you really want to allow users/deployed-apps/3rd-party-libs

 * call System.exit()?
 * change behavior of the whole JVM by changing some system properties (keystores and truststores for instance)?
 * use reflection to read/change private data (caches, etc)?
 * access the filesystem (e.g. rewrite the WildFly configuration files)?
 * ...

If the answer is always yes, then you don't need the JSM I think.

But if you care what can do the parts of code which you don't have under full control, then you should really use the Java Security Manager.

Best regards,

-- Josef

----- Original Message -----
> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "Jason T. Greene" <jgreene at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Saturday, April 19, 2014 7:43:24 PM
> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion
> 
> Hi,
> 
> Just wondering, but what is the primary use case for a security manager
> server side?
> 
> While the model obviously makes sense for Applets and Webstart where
> untrusted code is executed on the user's machine, I found it to be extremely
> rare for a server to run untrusted code. In fact, I don't think I've ever
> seen this situation.
> 
> There's maybe a case to prevent privilege escalation in case of a legitimate
> app being hacked, but in practice it doesn't look like a security manager is
> really being used a lot for that, is it? Instead the default thing to do
> there seems to be to run the AS under a user with limited rights on the host
> OS and/or use things like SELinix or Virtual Servers (e.g. XEN) to isolate
> the complete AS.
> 
> Kind regards,
> Arjan Tijms