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

[Andrig Miller]

----- Original Message -----

> From: "arjan tijms" <arjan.tijms at gmail.com>
> To: "Josef Cacek" <jcacek at redhat.com>
> Cc: "WildFly Dev" <wildfly-dev at lists.jboss.org>
> Sent: Wednesday, April 23, 2014 7:54:43 AM
> Subject: Re: [wildfly-dev] my 2 cents on Security Manager discussion

> 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.
I would add here, that you may start off not trusting some code you want to use, but if that code is open source, then you can audit that code for any malicious behavior. Open source libraries, as third-party dependencies has become the norm too. 

Andy 

> 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

> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20140423/c4ea9d88/attachment-0001.html