Re: [wildfly-dev] my 2 cents on Security Manager discussion
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(a)gmail.com>
To: "Jason T. Greene" <jgreene(a)redhat.com>
Cc: wildfly-dev(a)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