PrivilegedAction et al and JEP411

[Peter Firmstone]

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.firmstone at 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