Some quick clarifications, I'll try to reply properly in the next few days.
On 17/05/2021 9:29 pm, Ron Pressler wrote:
On 17 May 2021, at 06:19, Peter Firmstone <peter.firmst...@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
Thanks for the link, I am aware of it.
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.
I understand the direction and the reasons for the decision, however we
still need to consider how it will impact those who utilise it, and I'm
sure more examples will come to light in time.
In my case, yes of course it will be less secure, because I'm using the
stack context to manage access decisions for remote service identity.
These service proxy's now have some very limited permissions, in future
their access will be completely unrestricted. It is a foundational
feature, it has a significant impact on those who adopted 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.
This is an existing system, your arguments are not relevant as the cost
of rewriting millions of lines of code is prohibitively expensive.
Services written in other languages may be providers of services,
however other language runtimes may not be consumers of services because
most lack dynamic class loading or dynamic fine grained access
control. The JVM is required to allow services to be agglomerated into
a system.
My point is that there will be no restriction on the services themselves
in the JVM consuming and using the services. Currently service proxy's
are only allowed to contact their originating server and negotiate a few
required permissions for their operation. In future versions of Java
without a SecurityManager, they will have no restrictions at all.
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.
Yes, it is the case for software that was designed to use the
SecurityManager. We need to be honest about the impact, yes I
understand SecurityManager will be removed, however telling developers
their EXISTING software is no less secure is inaccurate.
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.
Barely used or not, it is only fair to acknowledge the impact on those
who do use it.
Are you a security expert? Is this your opinion as a security expert?
I don't need a sandbox, I need access control.
Your proposal is quite plain and simple, I don't see how it can be
misunderstood, you propose to remove the ability to make stack based
domain, access control decisions.
These sandboxes you talk of, I have not seen any practical workable
solutions, I'm assuming your talking about Intel architecture based
Virtual Machines that host an OS, they don't provide dynamic access
decisions for Java? Yes I acknowledge they can do static, but not
dynamic performant access decisions.
I suspect either you don't understand what I'm talking about, or you
simply don't want to acknowledge it. I have provided links to fully
functional software that utilises SecurityManager.
We should just say, that there is no future migration path for existing
Java applications that require fine grained access control.
It's quite simple really, just be honest.
I've accepted OpenJDK is doing this, I just want you to acknowledge that
Java in future will be less capable in this respect than the Java of
today, so that people who might be impacted take it seriously.
What I intend to do about it, is contribute to existing versions of Java
to prolong their life.
I'm looking for acknowledgement, so that the importance of maintaining
Java 17 for a long time is understood for existing applications that use
fine grained access control, which have no other alternatives can
continue to remain functional and secure, up to date secure.
Hand waving brush off comments don't provide practical workable solutions.
I think for starters we should discourage those who require fine grained
access control from using newer versions of Java that don't implement
it. Then it would be nice for those who would like to help maintain an
existing version of Java that does support fine grained access control
to do so as a part of the OpenJDK project.
I don't understand why this is so objectionable?
It really doesn't matter what 99.99% of other people are doing for the
0.01% that use it. You conveniently plucked these figures out of thin
air, a word of advice, it lessens the credibility of your arguments.
— Ron
--
Regards,
Peter Firmstone
