On 29 Apr 2021, at 13:06, Peter Firmstone <peter.firmst...@zeus.net.au<mailto:peter.firmst...@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
