[External] : Re: PrivilegedAction et al and JEP411

[Peter Firmstone]

Thanks Erik,


This is the best argument I've heard for removal so far.   Note that I 
understand it will be removed, I'm not arguing to keep it, we are stuck 
with versions of OpenJDK that provide it, as there are no migration 
options, I was hoping we might be able to reimplement it, but it's not 
possible without some low level language support.  If someone does think 
of something one day, a way that allows us to implement it, without 
great cost to OpenJDK, I would appreciate if you would keep us in mind.


> It isn’t. We have nothing to gain from removing a feature whose 
> benefits outweigh its cost, and removing a feature is itself a rather 
> costly process. Not to mention the negative social dynamics: the 
> majority don’t care and don’t know what they gain, while the minority 
> who use the feature become understandably upset. It’s unpleasant all 
> around. So if we do it, we’re sure the cost of the feature is high.


If you are able to share, I'd be interested to learn about challenges 
you had with SM, if we one day have the opportunity to reimplement it, 
the lessons might be valuable, so we can avoid the same mistakes.


To quote Thomas Sowell: "There are no solutions, only trade-off's."


Since we brought up encapsulation and serialization, which has been the 
cause of many Java security issues, there is one performance / security 
trade-off that I'd like to mention. Serialization filters are lazily 
initialized, this is a performance optimisation (a security trade off), 
however if a program doesn't utilise serialization and has disabled 
serialization using a filter, this provides an opportunity for an 
attacker.  For the attack to be successful, the attacker needs to change 
the serialization filter properties, prior to initialization, if the 
attacker is successful, they will be able to disable the only security 
mechanism protecting de-serialization against attack.


Serialization filters are an "allow list", Security Policy also uses an 
"allow list", it would have been possible to add a simple permission 
check during de-serialization, and we could have captured the classes 
using tooling, it would have saved a lot of work creating serial 
filters, but understandably, the code in OpenJDK, especially the policy 
provider performs poorly, so I can see why the decision was made to 
implement serialization filters separately, but had it had some 
continued love when Java 5 introduced concurrency, and more tooling had 
been built up around it, perhaps today it would be simpler to use and 
more widely adopted...


The problem with "allow lists", and serialization is, it still lacks 
encapsulation, so the vulnerability remains, this is why authentication 
is important, who are we allowing?   When we boil it all down, we call 
it Authentication and Authorization, perhaps there will be something new 
that provides this functionality again one day, and maybe the lessons 
learned will provide a better trade off.  That's why I'd like to 
understand the challenges you had with SM. :)


Regards,


Peter.



On 23/06/2023 12:35 am, Erik Gahlin wrote:
>
>     > I'd suggest cost of maintenance also appears overestimated
>
>     It isn’t. We have nothing to gain from removing a feature whose
>     benefits outweigh its cost
>
>
> The cost is very high. I've spent probably a year on the SM just for 
> jdk.jfr module.
>
> Erik
> ------------------------------------------------------------------------
> *From:* security-dev <security-dev-retn at openjdk.org> on behalf of Ron 
> Pressler <ron.pressler at oracle.com>
> *Sent:* Wednesday, June 21, 2023 12:52 PM
> *To:* Peter Firmstone <peter.firmstone at zeus.net.au>
> *Cc:* chap at anastigmatix.net <chap at anastigmatix.net>; 
> security-dev at openjdk.org <security-dev at openjdk.org>
> *Subject:* Re: [External] : Re: PrivilegedAction et al and JEP411
>
>
> > On 21 Jun 2023, at 01:36, Peter Firmstone 
> <peter.firmstone at zeus.net.au> wrote:
> >
> >
> > I'm just disappointed that we are being prevented from 
> reimplementing a replacement authorization layer in Java, without any 
> compromise from OpenJDK it's not possible.  We at least need to retain 
> some kind of privilege action mechanism.   That doesn't even have to 
> be a privileged action, maybe it could be an annotation, that we can 
> find using StackWalker.
>
> Maintaining that information is the very thing that makes the 
> mechanism so expensive. Annotations wouldn’t make it any easier, 
> because their placement would still have to be tested and maintained. 
> No one is preventing you from maintaining that information yourself, 
> and you are free to inject such annotations into the JDK to your 
> heart’s content. If it really isn't too much work then we all win — we 
> don’t have to do it and test it, and you still get to have it.
>
> > If data protected isn't of high value, or is of low complexity, a 
> solution of appropriate cost will be applied, in many cases that isn't 
> SM, however removing SM will reduce security below an acceptable level 
> for a percentage of developers and software projects, the number may 
> be small, but the impact will be widespread, just look at how widely 
> deployed ElasticSearch and OpenSearch are.
>
> That is clearly untrue because even the most security sensitive 
> applications already prefer alternatives that they find superior. 
> We’re not sending people over to other alternatives; people first 
> abandoned SM in favour of alternatives and *then* we figured it’s time 
> to remove SM when few were left using it. I believe ElasticSearch are 
> now relying on strong encapsulation to maintain their Java-level 
> security invariants.
>
>
> > Arguments against SM, that I've read on this list are based on bad 
> practises, or the lack of tooling provided with the default 
> implementation, this indicates a lack of experience in use, I know 
> that Alan and Sean were involved during the early days with Li Gong, 
> but I'm pretty sure they don't have much experience deploying it, feel 
> free to prove me wrong if my assumption is incorrect.
>
> While we disagree — and the “ground state”, i.e. what’s available 
> without SM is very different today from what it was in 1997 — it isn’t 
> our job to prove you wrong because even our most security-conscious 
> users demand something else. If you’re absolutely certain that you 
> have the answer, then it is you who have to prove us wrong by making 
> your answer popular.
>
> > I'd suggest cost of maintenance also appears overestimated
>
> It isn’t. We have nothing to gain from removing a feature whose 
> benefits outweigh its cost, and removing a feature is itself a rather 
> costly process. Not to mention the negative social dynamics: the 
> majority don’t care and don’t know what they gain, while the minority 
> who use the feature become understandably upset. It’s unpleasant all 
> around. So if we do it, we’re sure the cost of the feature is high.
>
> > , this is partly due to policy, I have offered to assist with 
> maintenance, however my offer was rejected, as this is considered part 
> of security, I am not permitted to assist, I could submit patches to 
> this list, but I'm not sure they'll be welcomed or accepted.
>
> The resources you can contribute aren't nearly sufficient and, like I 
> said, the problem is that maintaining the doPrivileged information is 
> not localised but imposes a tax on *everything*.
>
>
> > however I've assumed that as it's deprecated, there will be little 
> interest in fixing them, is my assumption incorrect?
>
> Actual bugs will have to be fixed until the mechanism is fully 
> degraded, but you are generally correct.
>
> >
> > Lets discuss how it should be used, and what benefits it provides 
> and the situations when you might want to use it.    I only ask that 
> people keep an open mind and for the moment, forget all the horror 
> stories.  I realise this is academic now, and unlikely to change 
> anything, however documenting it here might serve some historical purpose.
>
> Okay, but we, .NET (the other platform that had a similar mechanism), 
> and most security experts have lost faith in the approach and gained 
> faith in newish OS-level protections that weren’t available when SM 
> was introduced (and also offer protection for native code as well as 
> better protection from some DOS attacks); no new security sensitive 
> platform seems to take that stack-based approach, either. This means 
> that even if we’re wrong on the technical merits, such a feature is so 
> far from the mainstream practice that it has no room in a mainstream 
> language. If some day it becomes mainstream again things may change.
>
> Still, here’s one thing about the technical aspect: “Trusted” does not 
> mean “free of vulnerabilities” but "assumed to not be malicious.” 
> Libraries can and do have vulnerabilities, but I think that strong 
> encapsulation is much more effective in controlling their blast 
> radius, and it has significant non-security-related benefits, too (not 
> that most developers are rushing to apply strong encapsulation to 
> their own code, but at least we’re able to encapsulate the JDK 
> itself). By “effective” I don’t mean “powerful”, but rather “provides 
> more value on average when all aspects are considered”. With strong 
> encapsulation you only need to check that a particular code unit that 
> performs an operation on behalf of a user (authorised at the 
> application operation level) doesn’t do anything problematic. Other 
> units cannot break your unit’s invariants, so only local reasoning is 
> required (true, the size of the unit is not as small as could be 
> afforded by a stack-based approach, but it is still local and 
> contained). If you’re interested in gadget attacks, I suggest you 
> think about how many of them can be prevented by strong encapsulation 
> alone and how many could be prevented by a combination of strong 
> encapsulation and OS-level protections that apply to the entire 
> process (you can throw in serialization filters, too). In other words, 
> don’t think just about what SM could do for you, but also think about 
> what the more popular approaches do for you, too (taking your own 
> advice of considering how they can be best applied, not misapplied) 
> and then consider how much effort should be put to close the *delta* 
> between the two.
>
> Code signing is a completely separate topic; expect some developments 
> in that area.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230623/d022769c/attachment.htm>