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

[arjan tijms]

Hi,


On Wed, Apr 23, 2014 at 2:40 PM, Josef Cacek <jcacek at redhat.com> wrote:

> 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)?
>  * ...
>

It's not about wanting that or not wanting it I think. It's about the
question if you run code that you trust or not on your server. If you don't
trust your code, then you may indeed be tempted to put up guards against
calling System.exit(), etc.

But...

In practice, in at least my experience, it just doesn't happen a lot if
ever that you run untrusted code on a server.

In the majority of the cases the code I and my team deploy is the code that
I and my team have written. We don't need to protect ourselves against
calling System.exit(). If we suspect that a library that we use would be
potentially malicious enough that it called System.exit() or did other
nasty things then we just don't use it.

Since in the overwhelming majority of cases you totally control the code
and all its dependencies on the server, there's no need to put guards in
place. Either you trust the code and use it, or you don't trust the code
and then don't use it. As soon as someone would feel a need to put a guard
in place, then it means the code isn't fully trusted and thus the decision
not to use that code has already been made IMHO.

And particularly about the "users" in "to allow
users/deployed-apps/3rd-party-libs": the permissions you mentioned are all
*code level* permissions. Users aren't code, but interact with your system
via its UI. So naturally you need a lot of user level permissions, but this
is something else than code level ones.

Kind regards,
Arjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140423/86bfef9f/attachment.html