On 17 May 2021, at 21:46, Peter Firmstone <[email protected]> wrote:
Yes, you are talking about those who maintain and develop OpenJDK, but this is
only a small proportion of the overall Java developer ecosystem.
Not at all. I’m talking about the millions of developers who don’t get what
they need sooner because the
OpenJDK’s resources are invested in maintaining components that add little
value to the ecosystem.
No, it's not practical, but there's no viable upgrade path, so our only option
is indefinite maintenance of Java 17.
I’m not going to tell you where to put your money, but writing a Java agent is
orders of magnitude cheaper
than maintaining an eight-million-line codebase indefinitely.
In a distributed system that uses POJO's and Remote Method Invocation, a proxy
is used to invoke methods on an object in a remote JVM or any other language
for that matter, operating in another node or process. The proxy
implementation is not known, nor necessarily are it's communication methods
until runtime. It is loaded dynamically.
The proxy is trusted code (each implementation has different bytecode), but we
wish to run it with principles of least privilege, rather than an anything goes
approach.
https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEEqMlozJA$
I’m not sure I understand. If you’re not talking about a JDK mechanism, you can
change that mechanism
to not use the Security Manager, just as JAAS will be changed.
If the application needs access control, but the Java platform doesn't provide
it, and you must remove it for the application to run, then yes, the software
will be less secure as a result. This shouldn't be difficult to understand.
I understand but disagree.
No, but it is a useful security layer to control access.
The utility of *this particular mechanism* does not justify the cost of
maintaining it.
The question isn’t if such a mechanism could be useful or not, but is this the
best use of resources to improve security?
In other words, the choice isn’t between this and nothing, but between this and
everything else.
It is not possible to implement fine grained access control in Java, or as a
library, this feature is low level JVM code.
Again, when you say fine-grained level access control you don’t mean
fine-grained level access control but the
particular features provided by the Security Manager; and those features — at
least those you sound most interested
in — are not low-level JVM code, and can be implemented in Java with a Java
agent, at least as an additional, albeit
imperfect layer of security, if you think this is a worthwhile and
cost-effective approach.
Developers who wish to develop new applications that require access control
should do so using another platform, those who have existing software
deployments, need to stay on Java 17 for example, indefinitely until EOL.
I strongly disagree; the Security Manager is not the only — and I would say
it’s not even the best — way to
offer access control. This JEP proposes removing Security Manager. That that
implies giving up on access control
is entirely your insistence on identifying the two. And if the only way you can
think of implementing access
control is with a call-stack code-sourcing mechanism, then I’m afraid other
platforms are not going to offer it,
because they also don’t share the view that this is the best, let alone the
only, way to do this.
New developments that require access control might consider the Microsoft CLR
for example, however I'm no expert, there may be better alternatives.
https://urldefense.com/v3/__https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEF_yAtVXw$
.NET have also dropped their analogous mechanism; they, too, have become
convinced that different permissions
to different code *in the same process* is not a the best approach to security
today in cost/benefit.
Erlang, another platform with a strong emphasis on distributed systems also
does not provide this mechanism. I am not
aware of any platform that does.
To restrict operations to the principle of least privilege.
The principles are known, but not every additional layer is worth it at any
cost.
The code is not known at compile time, it is dynamic, such that it is only
known at runtime, this means that to use the Java Agent mechanism, one must
intercept every network and file system access, then try to determine where the
call originates, to see whether it can be allowed or disallowed.
The Java agent can insert the same instrumentation points as the Security
Manager in JDK code, and the equivalent
of protection domains will be determined by the framework and stored and
manipulated as ThreadLocals. StackWalker
provides what you need for determining caller classes.
There is no feature in Java past release 17 that would interest me enough to
perform this amount of work on an existing application, nor would it even be a
viable option if I wanted to. So I can't pay for it even if I want to, as it is
unaffordium.
I am sorry, but asking the majority of Java developers who prefer other
approaches to pay for it is even less fair.
I'm looking at how to support existing deployments that utilise existing Java
access control features.
Your world sounds more of a static compile time, everything is known up front
environment, mine is dynamic and flexible and unknown until after a process has
been running for some time.
I think that instead of working on finding alternatives that would make the
cost structure of something
few people want, you’ve decided that the existing mechanism is the only way to
do it.
However I suspect that you haven't got JEP 411 over the line yet and you are
worried that open discussion of the issues it causes may stop it, because it
impacts something you are trying to implement. I apologize if this discussion
inconveniences you, but it's still relevant and we should be looking at
maintaining a version of Java that supports access control for a very long
time, not 8 years.
You have to convince the relevant maintainers, and this discussion does not
inconveniences me because I’m just trying to
see if there’s something we missed. The Security Manager does not harm the
development of any one particular feature
because new features have already largely overlooked it with few people even
noticing. It does, however, take a
significant toll on resources that could be put to better use elsewhere,
including features that improve security in
a more cost-effective way.
The only other alternatives is either a complete rewrite in another language,
or forking Java, but neither seem viable.
I don’t think this is the only other alternative at all, and repeating this
claim is not something that, I think, will
help delay this JEP. Evidence that thousands of companies rely on the Security
Manager for security might, but short of
that I think your time would be better spent on trying to suggest alternatives
to some critical pieces that might be
acceptable cost-wise.
I wouldn't recommend a new development that requires access control to consider
using the Java platform at this time.
OK.
I'm unable at this time to advise where people should look as I'm still in the
investigation stage myself. If someone does know of other platforms that do
access control well, please inform me.
If by “well” you mean the way that you currently do it and you’re not willing
to even consider alternative approaches,
I think you might be disappointed.
— Ron
