At the same time, the sheer number of CVEs relating to sandbox
vulnerabilities and privilege escalations should give anyone pause, who
thinks to rely on an SM as a way to "safely" run untrusted code.
And an SM doesn't protect you from everything; untrusted code could, for
example, still lock threads into infinite, uninterruptible loops.
Finally, as I've said numerous times before, adding a security manager
has a performance cost - sometimes a *major* performance cost. You have
to balance all of these concerns against what your real requirements are
before you take the plunge.
On 04/23/2014 07:40 AM, Josef Cacek wrote:
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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML