I'm grateful for everyone's ideas and feedback, in the coming days &
weeks I'll put together some documentation to summarize and put some
time into some proposals, I have a lot of experience with the SM
infrastructure and its inner workings, having had to work around it's
pitfalls.
Watch this space, I'll post a link when ready.
Regards,
Peter.
On 5/08/2021 7:27 am, Sean Mullan wrote:
On 8/3/21 8:10 PM, Peter Firmstone wrote:
On 4/08/2021 2:40 am, Sean Mullan wrote:
On 8/2/21 8:28 PM, Peter Firmstone wrote:
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).
As mentioned several times, this use case will be preserved and is
already covered in JEP 411:
https://openjdk.java.net/jeps/411#subject-doas
Yes, that's true, a secondary consideration is the amount of work that
will be required to support different versions of Java, no doubt
reflection will be helpful, to check for the existence of the new
methods. Last time I checked, I have around 1,000 locations in the
code that will require changes. My motivation for mentioning it was to
highlight the benefit of reusing existing methods, which currently
provide this functionality.
This is a case similar to AccessController.doPrivileged where we could
potentially keep the existing APIs in place for a longer time period
until such time the compatibility risk is low and
applications/libraries have had ample time to convert to the new APIs.
See the paragraph about degrading APIs in JEP 411:
https://openjdk.java.net/jeps/411#Description
As an interim step, the existing APIs could be adapted such that they
simply call the new APIs which will likely use a different mechanism
to transfer the Subject across API boundaries (ThreadLocals or
eventually Scope Locals, when they arrive).
2. All remote connections are authorized to load classes.
Not sure why you can't do something with a custom ClassLoader that
only loads classes for authorized users.
Interesting, what do you have in mind?
I don't know, it was mostly just an idea I am throwing out based on
your #2 statement above. I don't have the time to fully understand
your model, but more simply if you know who is authorized and who
isn't, it seems like you would have direct control over what the users
are authorized to do and instead of relying on the Security Manager to
catch operations already in motion, you could prevent them before they
even occur. This seemed like one of those cases.
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.
You may have some interesting ideas, but in my opinion you have not
presented them in a clear and easily digestible manner, and your long
emails are time consuming to read, repetitive and often diverge into
rants. (Keep in mind there are many people on the jdk-dev alias, and a
lot of them may not care about this topic). It is to the point where I
only skim your emails quickly. I would take the time to write up your
ideas in an external place. It may not go anywhere, but at least you
would have a single place where your proposal, experiments, etc are
documented.
It's a two way street, I'm currently penetration testing OpenJDK dev's
to discover their pain points with SM architecture, as they haven't
documented them in JEP411. When I am sure I have discovered your pain
points, I plan to document a proposal. There's no point writing
something up that address the wrong pain points.
On that topic, I think for historical purposes, JEP 411's wording could
more accurately reflect the experiences of developers who overcame the
shortcomings that beginners experience with SM. JEP 411 does well to
document beginners experiences when first attempting to use SM, however
I think this unfairly penalizes the original authors, history should
look more kindly on their achievements. SM is a great achievement that
stood the test of time for over 20 years, and no one else has succeeded
at this task, it's not perfect, but it works well for those who are
using it to it's full potential. It's association with Applets and
their use of ClassLoaders as a weak form of isolation, and the resulting
permission sprawl that eventuated as band-aids to each vulnerability, is
unfortunate.
I don't disagree that the SecurityManager was a significant
achievement. But I think JEP 411 presents a fair picture of how it
played out over the years, and captures the main issues that most
users and developers faced when trying to use or deploy it.
--Sean
