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

David M. Lloyd david.lloyd at redhat.com
Wed Apr 23 08:57:29 EDT 2014


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 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
- DML


More information about the wildfly-dev mailing list