Don't get me wrong, it's good that OpenJDK is improving encapsulation,
it's just OpenJDK is also undoing years of tested and hardened API's,
that we're expected to come up with DIY solutions for, with zero care
from OpenJDK and some very bad examples of alternative solutions, not to
mention a completely wrong assessment of SM based on an outdated poorly
maintained implementation, with lack of use and maintenance burden (when
the community is willing but not allowed to maintain it) as
justification for it's removal.
SecurityManager is just an authorization layer (that allows assigning
different levels of trust), not a magic wand designed to solve all
security problems (or sandbox, it was only a component in the sandbox,
along with bytecode verification and ClassLoader visibility), to be
discarded because it doesn't solve some other unrelated security flaw,
it's an Non Functional Requirement, it doesn't bring in any revenue for
Oracle, nor does it for many other development projects, so management
have knocked it on the head, we get it. SM's only benefit is a little
more sleep at night as a mitigating factor in avoiding becoming
tomorrow's news headline. It might not be perfect, it could be better,
it's just the best authentication layer currently available, which makes
Java an enterprise ready solution. So now Java is only marketed for
server code, where all code must be trusted and audited prior to
deployment, it has me wondering if OpenJDK will be removing dynamic
ClassLoading in future, we don't need that for static code do we? Don't
answer that, I'm being sarcastic.
We know that Oracle intends to remove authorization from the Java
platform, we also know that there is nothing we can say to convince
Oracle it's a bad idea, the only thing management will understand is bad
consequences, such as bad news headlines. I understand that Oracle
needs to monetize Java, they've done a great job reviving Java from
where Sun was failing and it's given us many more years of Java.
Elasticsearch is a good example of SecurityManager applied properly,
there are many other things that Elasticsearch does, in combination with
SecurityManager to secure their platform, SecurityManager is only a part
of their security strategy. Security is like a chain, remove a link and
the chain is broken, no one's offering to repair the chain, OpenJDK is
only attempting to reassure us we don't need that link, but experience
tells us the chain is broken. We've been working hard at implementing
authorization for many years, to protect against attacks, but suddenly
the threat is gone? Yeah right, there's a bridge in Brooklyn for sale.
https://spinscale.de/posts/2020-04-07-elasticsearch-securing-a-search-engine-while-maintaining-usability.html
The decision has been made, it's final, the debate is over, we're just
waiting for the removal notice now. How about someone raise a JEP to
remove security manager, targeting a particular release version
(preferably 22, but so be it if it's 21) so we can remove uncertainty
and notify our users of the versions of Java we'll be supporting going
forward? Then it's over and we can stop worrying about it.
There's a cloud outside and I've got some yelling to do.
--
Regards,
Peter
On 20/06/2023 1:11 am, Ron Pressler wrote:
On 19 Jun 2023, at 12:48, Peter Firmstone <peter.firmst...@zeus.net.au> wrote:
For most Java developers, and Jvm users, it means that all Java bytecodes need
to be audited and trusted,
That has always been the case for *server* applications because SecurityManager
has never protected against some of the most common attacks against servers.
Secure servers employ OS-level defences, and that’s the approach the vast
majority of secure Java servers — and secure servers in any other language —
already take.
However, note that with "integrity by default"
(https://openjdk.org/jeps/8305968) Java is now making it easier than ever before to
establish invariants locally and trust them globally regardless of what any other code
does. This is precisely to allow more robust reasoning about important program
properties, whether they’re used for correctness, security, or performance. It also
establishes a more robust and convenient separation of responsibilities among the
different layers — hardware, OS, JVM — over which invariants they each maintain.
— Ron
