Thanks Alan,
Concurrency is difficult too, but Java has gone a long way to addressing
this with concurrency libraries that make the task seem like child's
play, compared to using Java 1.4 language constructs.
On 31/05/2021 5:59 pm, Alan Bateman wrote:
On 31/05/2021 08:11, Peter Firmstone wrote:
:
I think also that many more people are using SecurityManager than
OpenJDK realises, and they're not using it how OpenJDK recommends
either, (AllPermission granted to trusted code, and sandbox untrusted
code model of Applets is not how we use it) people are using POLP,
it's just that no one reports back to OpenJDK because they are only
editing policy files, it will work with any library out there now,
there's nothing to write back about. It's pretty clear that OpenJDK
devs don't use it, but they do have to manage doPrivileged and
preserving context across tasks and threads.
And there are static analysis tools in Spotbugs to identify
doPrivileged bugs, but someone has recently suggested removing them
thanks to this JEP? Does OpenJDK use static analysis. I think if
you did you'd find plenty of latent bugs.
I don't think the SM is approachable by most developers. I've sat
through several embarrassing sessions at conferences over the years
where a speaker attempted to get something non-trivial to work with
the SM enabled. More often than not they had to deal with libraries
that had never been run with a SM before and it was whack-a-mole to
get them to run.
Yes, it shouldn't have been allowed out the door without a tool for that
reason, it could have been avoided. Yes, I have a tool that sorts
that very problem, it's 500 - 600 lines of code. Just specify two
command line arguments which are the security manager and policy file
location, it generates the policy file, then you look at the file
briefly, alter some permissions like network for ephemeral ports, easy,
you now have a POLP policy file. You do need to properly run the
program through its use cases however, but testing is often sufficient,
even if you don't have full test coverage it will capture 99.9% of
permissions required, then if you tests are missing a permission, it
indicates insufficient test coverage. The tool will also append, so you
can run multiple processes and user roles one after the other.
I will rewrite it in GPL2.0 if you ask me to. The only reason I didn't
get around to it before was it's AL2.0 and there wasn't an existential
threat to SecurityManager API's.
As you know, any library or framework with callbacks means careful use
of doPrivileged to avoid needing to grant permissions to every
component on the stack. You mention capturing and re-asserting
contexts across threads, this is just way too complex for most
developers. My guess is that if we had enabled the SM by default 20
years ago then it would be a different discussion today. This is not
to say that there isn't some usage, the flurry of mails here over the
last month does show that there is some usage. The SM survey in 2018
showed that there was some usage too.
Yes, so how do we start that process? It doesn't matter if we start it
now or 20 years ago, as long as when it does happen the outcome is
positive, I have been coming across more and more developers who
implement POLP or that want to. Executors has two methods which
decorate Runnable and Callable, but they could be placed into the
Executors and performed automatically when tasks are submitted, when
SecurityManager is installed.
We could give developers a choice, so loom threads are zero privileged
by default or are treated as doPrivileged calls with the Subject of the
creator, so it only has one ProtectionDomain and load it with immutable
collections of permissions, then we can use them for TLS connections if
we want or leave them unprivileged. It's a fair compromise, just make
sure the callers domain has minimal privileges. It seems to me that
loom would be very good for blocking IO. It only needs to be
documented, then we will use it appropriately.
In my SecurityManager implementation, once an AccessControlContext has
been checked for a Permission, it is only ever checked again if the
policy is refreshed, so it's a once off which has little impact in an
Executor pool. It uses concurrent collections that are decorated with
weak references, to avoid memory leaks.
I can't speak for all OpenJDK contributors but Oracle contributors do
a massive amount of analysis and static analysis before proposing to
deprecate or removing anything. It's often much harder to remove
something that add it and I don't think anyone has proposed
deprecating or removing anything without a strong case.
-Alan
I understand, but this is incredibly useful software when POLP is
applied and if promoted properly with good tooling and documentation it
addresses a lot of technological issues that are receiving much more
attention, millions of medical records are stolen every year and
governments not getting along as well as we'd like?
https://www.wesh.com/article/millions-of-health-records-stolen-every-year/29988160
Could Java be the answer?
It can be modified and improved, it hasn't received much love for a long
time.
I'm sure it can be made much more friendly. Turn it into Java's
advantage instead, nothing else like this exists and we know and those
that do use it, understand it very well because it's been around such a
long time.
Peter.
