While I accept that my particular use case will no longer be supported
in future, it's difficult to see the value of a sandbox, because
developers will always want to relax it in some way and people fall into
the trap of thinking that trust is black and white; this is trusted,
that is not.
Nowadays, there's a lot more interest in the Principle of Least
Privilege, especially in health care regulations, now I'm going to use
the meaning implied in "Inside Java 2 Platform Security, Second
Edition", so that we aren't arguing whether that applies with the JVM or
external to it.
The reason POLP is simpler, is that it can be automated with tooling,
then the development / deployment team may choose to relax it, they can
certainly test it and validate it. Then we are simply focused on what
we need to do, rather than what we might want to restrict, which is
always unknown and subject to change.
The problem is that this is not how developers have been taught to use
SecurityManager, instead they are told that trusted code can be given
AllPermission because it's trusted and that's an approach which has
proven largely ineffective and the OpenJDK development team carry's the
cost as a result, with little benefit.
I just thought I'd provide you with a different perspective, so
hopefully the mistake isn't repeated.
Peter.
On 28/05/2021 8:09 pm, Ron Pressler wrote:
Deep sandboxes, simple or stack-dependent, are useful for very “rich” code,
that is potentially very big and possibly contains arbitrary third-party
libraries, while shallow sandboxes are more suitable to limited plugins.
While a complex, stack-dependent, deep sandbox *could* be used for plugins,
permissions that don’t specify what is forbidden but what is allowed
effectively also severely limit the use of third-party libraries, that
for example, might want to do benign operations with their own files,
and so effectively only allow very limited plugins. The result is a costly
mechanism that is overkill for what it’s used for.
— Ron
