Hello Andrew,
Loss of SM is a significant threat to my software, if left unresolved.
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.
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/ ?
https://www.oracle.com/java/technologies/javaee/api-design-implementation.html
In JGDMS without SM, at least the following must be addressed to
maintain security:
1. 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).
2. All remote connections are authorized to load classes.
3. All remote connections are authorized to perform deserialization.
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.
With SM all the above require authorization and authentication, such
that all remote connections are trusted and without malicious intent.
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.
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.
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.
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.
Thank you.
Peter.
On 2/08/2021 11:07 pm, Andrew Dinn wrote:
On 02/08/2021 11:33, Peter Firmstone wrote:
I think you may be misinterpreting my comment, let me clarify:
Really? I'd suggest only if you stretch the meaning of your words
beyond their elastic limit.
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.
. . .
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.
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.
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.
regards,
Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
