[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
Ron Pressler
ron.pressler at oracle.com
Mon May 17 11:29:19 UTC 2021
> On 17 May 2021, at 06:19, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
>
>
> In versions of Java, without a security manager, the third party service provider will have AllPermission, and the user will have restricted permissions (if we still have some form of user Permission based access control).
Follow this issue: https://bugs.openjdk.java.net/browse/JDK-8266592
> So basically we might as well remove all access control completely and say that all users and all code is completely trusted,
All users — no, and at this point I’m starting to think that, rather than trying to understand
the direction proposed here, which is ultimately meant to help make Java *more* secure, you’re
trying to intentionally misunderstand and/or misrepresent it.
>
> It does appear that a side effect of JEP 411, perhaps even an unintended consequence, will be to limit Java to trusted networks with one administrator. It is most certainly appears to be a single JVM focused change, or a system controlled by one administrator.
Absolutely not. 99.99% of secure distributed systems in the world, written in Java or not,
do not use Java’s Security Manager, and a great many of them mix of Java and other runtimes.
You might have a point, though, that the current direction does not try to tailor a specific
solution to distributed systems made *only* of JVMs, and, because systems are not controlled by
one administrator, and because many are polyglot, mixing services running on different runtimes,
this is very much the right direction to go. You, on the other hand, seem to be focused on
“Java only” systems.
>
> Newer versions of Java will of course be less secure without access controls and unsuitable for use in a distributed system that involves more than one administrator.
Of course not.
I realise you’re trying to paint a picture as if the removal of Security Manager, a barely used
component, would adversely affects Java security — contrary to the opinion of security experts — b
ut the fact is that the vast majority of Java systems today already use other security
measures, including sandboxes. I don’t know if you actually believe this, in which case you
misunderstand the proposal, or don’t believe it but think that such claims would sound convincing
to others.
It is true that we’re saying to those few remaining people who still depend on Java’s internal
sandbox to do what most other people have already done and rely on other security measures, and so
*if they do not* their systems will be less secure, but, of course, this is not what’s being
recommended. All this JEP is saying that the JDK itself will not, in the long term, provide this
particular fine-grained sandbox, and that remaining users should switch to other sandboxes available
to Java applications.
— Ron
More information about the security-dev
mailing list