<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks Erik,</p>
<p><br>
</p>
<p>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.<br>
</p>
<p><font size="2"><span style="font-size:11pt;"><br>
<blockquote type="cite"><font size="2"><span
style="font-size:11pt;">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.</span></font></blockquote>
</span></font></p>
<p><font size="2"><span style="font-size:11pt;"><br>
</span></font></p>
<p>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.<br>
</p>
<p><br>
</p>
<p>To quote Thomas Sowell: "There are no solutions, only
trade-off's."</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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...<br>
</p>
<p><br>
</p>
<p>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. :)</p>
<p><br>
</p>
<p>Regards,</p>
<p><br>
</p>
<p>Peter.<br>
</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 23/06/2023 12:35 am, Erik Gahlin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DS7PR10MB511853703F058D1F7AAEAE189D22A@DS7PR10MB5118.namprd10.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<div><br>
<blockquote class="userQuote" itemscope=""
itemtype="https://schemas.microsoft.com/QuotedText"
style="border-left-width: 3px; border-left-style: solid;
border-left-color: rgb(200, 200, 200); padding-left: 1ex;
margin-left: 0.8ex; color: rgb(102, 102, 102);">
> I'd suggest cost of maintenance also appears
overestimated<br>
<br>
<div>It isn’t. We have nothing to gain from removing a
feature whose benefits outweigh its cost</div>
</blockquote>
<br>
</div>
</div>
The cost is very high. I've spent probably a year on the SM just
for jdk.jfr module.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Erik</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
security-dev <a class="moz-txt-link-rfc2396E" href="mailto:security-dev-retn@openjdk.org"><security-dev-retn@openjdk.org></a> on behalf
of Ron Pressler <a class="moz-txt-link-rfc2396E" href="mailto:ron.pressler@oracle.com"><ron.pressler@oracle.com></a><br>
<b>Sent:</b> Wednesday, June 21, 2023 12:52 PM<br>
<b>To:</b> Peter Firmstone <a class="moz-txt-link-rfc2396E" href="mailto:peter.firmstone@zeus.net.au"><peter.firmstone@zeus.net.au></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:chap@anastigmatix.net">chap@anastigmatix.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:chap@anastigmatix.net"><chap@anastigmatix.net></a>; <a class="moz-txt-link-abbreviated" href="mailto:security-dev@openjdk.org">security-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:security-dev@openjdk.org"><security-dev@openjdk.org></a><br>
<b>Subject:</b> Re: [External] : Re: PrivilegedAction et al
and JEP411</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span
style="font-size:11pt;">
<div class="PlainText"><br>
<br>
> On 21 Jun 2023, at 01:36, Peter Firmstone
<a class="moz-txt-link-rfc2396E" href="mailto:peter.firmstone@zeus.net.au"><peter.firmstone@zeus.net.au></a> wrote:<br>
> <br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
> I'd suggest cost of maintenance also appears
overestimated<br>
<br>
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.<br>
<br>
> , 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.<br>
<br>
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*.
<br>
<br>
<br>
> however I've assumed that as it's deprecated, there
will be little interest in fixing them, is my assumption
incorrect?<br>
<br>
Actual bugs will have to be fixed until the mechanism is
fully degraded, but you are generally correct.<br>
<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Code signing is a completely separate topic; expect some
developments in that area.<br>
<br>
— Ron</div>
</span></font></div>
</blockquote>
</body>
</html>