On 18/05/2021 12:25 am, Ron Pressler wrote:
On 17 May 2021, at 13:47, Peter Firmstone <peter.firmst...@zeus.net.au> wrote:
It is a foundational feature, it has a significant impact on those who adopted
it.
True. But the problem is that it also has a significant impact on those who
didn’t.
Yes, you are talking about those who maintain and develop OpenJDK, but
this is only a small proportion of the overall Java developer
ecosystem. But I understand that this isn't insignificant either,
just like the features removal isn't insignificant to those affected by it.
Out of curiosity, was anyone here impacted by the oil pipeline shutting
down? Impacts can be direct and indirect.
This is an existing system, your arguments are not relevant as the cost of
rewriting millions of lines of code is prohibitively expensive.
I don’t think we’re talking about rewriting millions of lines of code, and the
cost of keeping
Security Manager is far greater, anyway. We want to shift the high cost of
maintaining the
SM, or something like it, from those who *don’t* want it to those who do, and I
think that’s more
than fair.
No, it's not practical, but there's no viable upgrade path, so our only
option is indefinite maintenance of Java 17.
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.
I don’t understand this statement. Which JDK-implemented “service proxies” are
you referring to that
today implement such a restriction in the JDK?
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://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS
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.
It is accurate, because if existing software picks a new runtime, then it will
have to be modified
in order to run at all, if only to acknowledge it is depending on a deprecated,
and later, degraded
feature. This JEP is proposing a responsible mechanism precisely to prevent
situations like applications
that do depend on SM for security suddenly become less secure without their
knowledge.
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.
So you could say, that the application has become less secure, with
their knowledge, because it has a task to perform and it will be made so
that it will continue to perform that task, even at the expense of less
security, because security has become the obstacle to operation, which
is the primary purpose, so security becomes a secondary concern. No one
will switch it off if it's insecure, at least not until after they're
hacked, then they'll look for bolt on security solutions and they may
get approval to rewrite the system at that stage.
Are you a security expert? Is this your opinion as a security expert?
I am absolutely not a security expert, which is why I talk to security experts
who tell me
they do not recommend the Security Manager as a central security measure.
No, but it is a useful security layer to control access.
Security should be seen as a layered approach, rather than one solution
fits everything. Each layer has it's role to play.
The use of SecurityManager as a central security measure is not the intent.
https://www.upguard.com/blog/principle-of-least-privilege
Yes the Java Permission model is flawed, one cannot disallow an insecure
network connection, while allowing a secure TLS authenticated
connection, however we've created other ways of doing that, but it does
rely on the Permission model to limit privilege.
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.
Not the ability, but the built-in implementation.
It is not possible to implement fine grained access control in Java, or
as a library, this feature is low level JVM code.
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.
New developments that require access control might consider the
Microsoft CLR for example, however I'm no expert, there may be better
alternatives.
https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/
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.
Depends what you mean by “dynamic.” They do not attempt to provide different
access to JDK capabilities
to different code-paths within the same Java process, which is why they are
preferable.
Dynamic means at runtime, not compile time or installation time.
We did look at using a separate process to sandbox untrusted code, but
it just didn't seem like a good idea to allow untrusted code to run at
all, at least not dynamically, one should run static analysis on it
first, but if it's a black box, you can only inspect bytecode, not
source and it can be obfuscated.
This is why authentication is still important, but even that can be
circumvented by a good attacker and shouldn't be relied upon as the only
defense.
We should just say, that there is no future migration path for existing Java
applications that require fine grained access control.
But that is untrue. First, let’s clarify that by “fine-grained access control”
you don’t mean the
ability of an application to allow or disallow application-level operations on
as fine a level as they’d
like based on, say, user credentials, but on the JDK blocking *JDK-level*
operations based on the code
paths that invoke them. Second, while the JEP does not offer a built-in
replacement for such a mechanism,
because few people want it and we believe it is not a good path for security
for Java these days,
if you absolutely want such a mechanism, you can inject instrumentation to
replace the built-in one
using the Java Agent mechanism, so there is a migration path even for this use
case.
That taking this particular migration path rather than opting for other
security measures is not trivial
only demonstrates why the Security Manager needs to be removed, as the people
paying for that work now
are those who *don’t* want it.
To restrict operations to the principle of least privilege.
https://us-cert.cisa.gov/bsi/articles/knowledge/principles/least-privilege
https://www.upguard.com/blog/principle-of-least-privilege
It would have been better if we could have assigned principles of least
privilege to Java library's too.
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.
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.
Besides we know what runs now is very performant, high scaling and
concurrent. It also runs with the principles of least privilege, so
if someone makes a coding mistake, it will be more difficult for an
attacker to take advantage of.
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?
Because your very specific and FAR from universal definition of “fine-grained
access control” does
all the work in this statement. It is not objectionable to say that Java will
not provide a built-in
mechanism that filters certain JDK operations based on the code-paths in which
they are accessed.
As you say, it's a small segment of the development base that needs this
feature, we should advise them to use a platform that supports it,
rather than try to get Java to do such things by bolting it on as an
afterthought. Security added later doesn't work, it needs to be
considered at the design stage.
https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/
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.
It is not my intention to convince you personally that the proposal is
justified. If you’d like to see the
proposal amended or withdrawn, it is *your* duty to convince those who made it
that it should be. If you
think that their assessment of the current value the SM brings to Java users is
incorrect, then it is
up to *you* to support that. I’m carrying on this discussion in the hope that
it might uncover some specific
point that we’ve missed — precisely because we take it very seriously and don’t
wish to brush off anything or
anyone -- not in order to get you to concede anything. For example, you
mentioned something about service proxies,
and it would be great if you could explain precisely what you mean.
Sometimes two opposing opinions can be equally reasonable, perhaps based on
different values, and yet only one
can be made. It is never our intention to get universal consensus for every
decision concerning such a large
ecosystem, or we’d never get anything done.
— Ron
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. The bytecode we wish to manage
access control of, may be written years after an existing deployment has
been running, we don't need to shutdown that deployment, or forklift
upgrade it, we simply add the new components, or nodes and they are
discovered dynamically at runtime and become an integral part of the
system automatically.
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. As part of this JEP or make
removal of the SecurityManager and associated components dependent on
another JEP that proposes maintaining a version of Java 17 for the
foreseeable future. This would be community supported version by those
who require it, maybe we can backport some things in later versions.
Simply because access control cannot be implemented as a library feature
or bolted onto the JVM as an agent instrumenting unknown bytecodes.
The only other alternatives is either a complete rewrite in another
language, or forking Java, but neither seem viable.
I wouldn't recommend a new development that requires access control to
consider using the Java platform at this time. As you say, it is only a
small number of developments, but they should look elsewhere.
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.
--
Regards,
Peter Firmstone
