We have updated the JEP with a few changes to the "Issue Warnings" section [1], summarized as follows:
If the Java runtime is started without setting the system property 'java.security.manager' then a custom Security Manager can be installed dynamically by calling System::setSecurityManager, just as in Java 16. No UnsupportedOperationException will be thrown. This call will, however, issue a warning message explaining that the Security Manager is deprecated and will be removed in a future release. We plan to change the default value of the 'java.security.manager' system property to "disallow" in the next release, i.e., Java 18. That will cause System::setSecurityManager to throw an UnsupportedOperationException in Java 18. With these changes, the process of deprecating and eventually removing the Security Manager will be consistent with our treatment of past breaking changes such as, e.g., the strong encapsulation of internal APIs. Maintainers of libraries and applications will be given fair warning before any existing code is broken. https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005616.html On Sat, May 29, 2021 at 12:04 AM Peter Firmstone < peter.firmst...@zeus.net.au> wrote: > 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 > >
