<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello Andrew,</p>
<p>Loss of SM is a significant threat to my software, if left
unresolved.<br>
</p>
<p>Your interpretations are your own, I make no apologies for your
interpretation. I am describing the difficulties that I am
experiencing with JEP 411 migration and how it applies to my
situation, it appears that others are having difficulties that
they have also expressed on OpenJDK lists, please understand that
it is not a trouble free experience, and as such some of my
frustrations may leak through into my writing. In my world, more
developers are affected, than are unaffected, but those are my
associations, not yours, your experiences may differ from mine.<br>
</p>
<p>What I have stated, is that existing deployed software that uses
SM for authorization access controls, has been designed around SM
and will become insecure if SM is removed. I refer you to the
following book, which our software security architecture is
designed around, I have not done research on the number of
developers or projects affected (I do not have the time or
resources). I do see quite a number of developers from various
projects have stated they will be affected in some way or another
on OpenJDK lists, have you followed any up off list, to understand
how they're impacted? Or have you written them off as /special
case/ /special loss/ ?<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://www.oracle.com/java/technologies/javaee/api-design-implementation.html">https://www.oracle.com/java/technologies/javaee/api-design-implementation.html</a><br>
</p>
<p>In JGDMS without SM, at least the following must be addressed to
maintain security:</p>
<ol>
<li>TLS and Kerberos connections cannot be established. (My
software is littered with doPrivileged calls that preserve the
Subject, we don't have anon TLS connections, we require client
certificates).</li>
<li>All remote connections are authorized to load classes.</li>
<li>All remote connections are authorized to perform
deserialization.</li>
</ol>
<p>This doesn't take into account user authorization, with SM gone,
it also means that all users and services now have all
privileges. I'm only documenting the major ones here.<br>
</p>
<p>With SM all the above require authorization and authentication,
such that all remote connections are trusted and without malicious
intent.</p>
<p>I have also presented a number of different compromises, that I
thought might address some of the maintenance cost burdens around
SM OpenJDK has, so that we might retain the most expensive
components to replace.</p>
<p>Having established that OpenJDK is not yet willing to compromise,
I have been attempting to create an authorization layer using
Agents, so that I can restore perimeter security following the
removal of SM and support future versions of Java. It is my hope
that either I will be successful in recreating an authorization
layer, or that enough people come forward and OpenJDK decides
there are enough affected developers to find a compromise that
either makes migration practical, or less expensive.</p>
<p>I have previously offered to donate code to OpenJDK, but I was
unable to get clarification on whether I could include AL2.0
licensed code from other authors, as my code is not my sole works,
two of whom have since passed away (only one at the time). The
remaining authors, I can still get in touch with and request them
to sign a contributor agreement, which I myself have signed. I
can separate out the parts which I am the sole author. For
example my RFC 3986 & RFC 5952 URI implementation is derived
from Apache Harmony under AL2.0. This work has been in
production for many years, and had no issues with the modules
added in Java 9, which allowed me to use common policy files in my
tests for all supported Java versions. It's used in both a
ClassLoader and a Policy implementation to avoid unnecessary DNS
calls. I have noticed that OpenJDK contains code under the AL2.0
license.<br>
</p>
<p>This has been a very frustrating experience, I'd suggest, if you
haven't got anything of value to add, or cannot be part of the
solution, please don't become part of the problem. I'm doing the
best I can to work within constraints to find a solution and am
trying not to be part of the problem by allowing my frustration
leak through, I've deleted more than I've posted, I suggest you do
the same and direct your attack onto problems, rather than people.<br>
</p>
<p>Thank you.</p>
<p>Peter.<br>
</p>
<div class="moz-cite-prefix">On 2/08/2021 11:07 pm, Andrew Dinn
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:dfcf1ecf-ce54-8ea1-34f5-0cb8fd8e7f75@redhat.com">On
02/08/2021 11:33, Peter Firmstone wrote:
<br>
<blockquote type="cite">I think you may be misinterpreting my
comment, let me clarify:
<br>
</blockquote>
<br>
Really? I'd suggest only if you stretch the meaning of your words
beyond their elastic limit.
<br>
<br>
<blockquote type="cite">I'm assuming that during the process of
removal of security manager, any external ports or process hooks
that we can only turn off now by not granting a permission will
be replaced by a command line property or something similar?
Eg, Agents, Management, etc. If this is the case, it would be
nice if they were set to off by default, such that they needed
to be enabled from the command line. It's a suggestion. . . .
<br>
</blockquote>
They might be or they might not be replaced -- and, indeed, you
are welcome to help the project to make that a possibility.
However, even if they were not replaced or enabled as default
behaviours the platform would not fail to be 'secure by default'.
At worst, it might be lacking belt and braces when it comes to
available means for enforcing some specific forms of control over
execution -- controls that can be used to resolve some security
problems, but not exclusively. Yet, you keep using language that
implies the loss of the security manager is a significant threat
to the security of OpenJDK/Java.
<br>
<br>
Claiming now that all you meant was that you would like to have
APIs that give you similar mechanisms to what is being removed
does not was and will not validate the use of such exaggerated
language. Nor do such statements give anyone confidence that you
are able to identify clear and compelling requirements and assess
the effort that might be needed to satisfy them and maintain an
implementation.
<br>
<br>
So, maybe you should just stop making out that your concerns are a
major problem to most developers and that they threaten the
integrity of the platform and instead concentrate on identifying
simple and maintainable APIs that we can feasibly add to OpenJDK
without incurring an unjustifiable maintenance burden.
<br>
<br>
regards,
<br>
<br>
<br>
Andrew Dinn
<br>
-----------
<br>
Red Hat Distinguished Engineer
<br>
Red Hat UK Ltd
<br>
Registered in England and Wales under Company Registration No.
03798903
<br>
Directors: Michael Cunningham, Michael ("Mike") O'Neill
<br>
<br>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>