JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

On 29 Apr 2021, at 13:06, Peter Firmstone <peter.firmstone at zeus.net.au<mailto:peter.firmstone at zeus.net.au>> wrote:

Is there a simpler way to limit permissions of library code?

Limiting permissions of library code is a spectacular idea, and the stack-dependent deep sandbox offered by the Security Manager
is the most spectacular software sandbox ever created. The problem is that while the idea is terrific, it does not seem to work
in practice in any way that is simple and scalable enough to give assured security for applications written by millions of developers.
That a select few could, perhaps, use it to build secure systems while the rest just get a false impression of security is not a viable
security strategy for a popular platform.

There are simpler, and therefore more scalably-secure ways to either sandbox an application or restrict the Java APIs
accessible to untrusted plugins. I don’t believe that semi-trusting and selectively sandboxing third-party libraries that otherwise
make use of the full range of Java’s core APIs is cost-effective and obviously secure. Companies need SMT solvers these days to
check the security of policy files that are much simpler than those that would be required to sandbox arbitrary third-party libraries.


Perhaps if we instead address the performance and usability issues, we could improve adoption,so it adds to Java's appeal, rather than detracting from it?

Let's take is as a given that everyone here is interested in adding to Java’s appeal, yet there might be disagreement over which
decision would do that. Clearly, those who propose removing the Security Manager believe it will add to Java’s appeal, if for no
other reason than freeing resources to features many people actually use, while also having a positive effect on security.

— Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210503/0320c64b/attachment.htm>