It looks like you got their attention. :)
Although we've had the assurance from OpenJDK that we could implement an
authorization framework using StackWalker and agents, I've found it's
not feasible, since privileged actions will be lost and there will be no
support from OpenJDK, it would destroy the principle of least privilege
that we currently have; permissions would have to be granted to all
domains on the call stack, privileged actions currently allow those
permissions to be limited, but clearly there is no way we can add this
functionality back after its removal. Defending a privilege is waste of
time if it has to be granted to everyone anyway.
In recent years, we've been seeing more and more permissions required by
JDK implementation code, leaking out, such as the following, our code
doesn't import any of these packages, but we have to grant permission to
our code, because JDK implementation code isn't using privileged actions
to access them, removal of privileged actions from the platform would
cause an exponential explosion in the number of permissions required.
permission java.lang.RuntimePermission
"accessClassInPackage.sun.reflect";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.action";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.ec";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.rsa";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.jca";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.krb5";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.pkcs";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.provider";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util.math";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util.math.intpoly";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.x509";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.util.locale.provider";
One of the lessons that have come from the discussions of JEP411, is we
can use agents to insert permission checks, where there are none
currently, so we'll be able to further lock down the JVM, than is
currently possible, this will allow us to make decisions on data
parsing, such as the trust relationship with the entity that provided
the data, it also means we can forget about the complexity of
serialization filters, by not allowing deserialization of data from
outside the JVM and limiting its use within, the best option is to
disable Java serialization completely of course, but then Java Flight
recorder, and other visibility tooling use RMI and Java Serialization.
One of the things I would have liked to do, would be to reduce the size
of the trusted platform, by restricting permissions for parts of OpenJDK
itself, this would only be possible if we rolled our own JDK, maybe
we'll do that one day, but we can't call it Java ;)
We try to support multiple versions of Java, from Java 8, up to the most
recent version, the only way to stay compatible will all versions is to
use deprecated API, hopefully OpenJDK will backport some of their new
API for developers who don't use SM.
Even we have small utility command line programs, where we don't use or
require authorization, where SM doesn't need to be enabled.
OpenJDK dev's have worked hard to improve encapsulation, however OpenJDK
has made it abundantly clear, that even if the community could maintain
and improve a feature, corporate has the final say and will do whatever
they want anyway, as much as I appreciate the hard work of OpenJDK
developers, corporate has the last say. We saw this previously with
JPMS v's OSGi, JPMS has no versioning capability, OSGi's service model
is superior to ServiceLoader, while everyone agrees JPMS is good for the
Java platform's encapsulation, my personal preference is OSGi for its
superior long term maintenance of application code, JPMS missed some of
the lessons OSGi had to offer. OSGi also has very good automated
tooling, which allows us to support it, without forcing our downstream
developers to adopt it. It isn't clear how to support both OSGi and
JPMS, it's not something we want to dictate to users, we want them to
have the freedom to choose, so we've focused on OSGi support, without
requiring users to adopt it.
It's also worth mentioning, the flaw in the argument that OpenJDK is for
server side programming now (a publish subscribe model, that only parses
data); that all code must be audited prior to deployment, the reality is
that Maven, the most commonly used build environment, pulls in a lot of
transitive dependencies that needs auditing and there needs to be more
tools to audit it, static analysis and known vulnerabilities are a good
start, but these don't capture everything, for over a decade we also use
SM for auditing, there currently aren't any tools that provide the same
level of visibility, perhaps there will be in future. But more
important than auditing alone, we can enforce what we audit. Until
something better comes along, we don't have a choice and must continue
using it.
Currently we use Spotbugs, Owasp and our own tool to determine
permissions required by software. Even if you aren't using SM in
deployed code, it's a good auditing tool and I'd recommend it's use
while it remains available, even if that means using an older JVM to
audit your code.
The tool can be found here, in case anyone is interested:
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/tools/security-policy-debug/src/main/java/org/apache/river/tool/SecurityPolicyWriter.java
Here's are some good videos I recommend people watch, if they find Java
security interesting, be warned however, ignorance is better if you
value your sleep:
https://www.youtube.com/watch?v=uVob-4aXbxY
https://www.youtube.com/watch?v=sIuVbVbjZcw
--
Regards,
Peter
On 19/06/2023 10:28 pm, c...@anastigmatix.net wrote:
On 2023-06-19 07:48, Peter Firmstone wrote:
Having an authorization layer, made it more difficult for attackers
to gain access to sensitive information, such as properties, especially
if you were using policy files with least privilege principles.
Agreed. I hope it did not seem as if my recent questions/suggestions were
directed at your efforts ... I meant them for the OpenJDK devs.
It does seem that the deprecation/removal of what's being called
"the security manager" does not signal a complete abandonment of
all aspirations for safety in Java. There is the strong encapsulation
in JPMS (unavailable when Li Gong's work was first done), and new
APIs like the foreign function and memory access are being designed
with an eye to restricting certain operations that could permit
arbitrary behavior. The new tactic seems to be to control such
operations by command-line options that permit the operations
only to specific named modules.
It seems that the approach being taken offers at least some
rudiments with which secure APIs might be built, albeit with
less configurability than the former approach (and no answer to
the confused-deputy problem). My own interests are chiefly in
being able to control access to operations outside the process:
file and socket I/O, process manipulation, and the like.
There seem to be some pieces of solutions to some of that.
There is a FileSystem API that allows a default implementation
to be specified on the command line at startup (and is passed
a reference to the underlying implementation, so it could be
used to mediate access). I seem to recall, though, a conversation
indicating the JDK may still have some file accesses that don't
use the newer API and so would not be mediated. While there is
obviously a bootstrapping challenge--some of those accesses
have to work early, before the FileSystem classes are ready--
making sure that all such remaining exceptions are fixed to
go through the new API once the early startup is complete
could be some low-hanging fruit for the OpenJDK devs to make
sure the platform at least offers a plausible way to control
those operations.
It likewise seems there is a SocketFactory API that could
be used to control those IPC operations.
I am not aware of any current API that could be used to
mediate Process or ProcessHandle operations, and that might
be another piece of low-hanging fruit.
I still wonder whether it is intended, after the last
stages of JEP 411, that all system properties will end up
being read-write. Quite a few of them now are read-only
sources of important platform information, and I'm not sure
what evaluation has been made of the possibilities for
mischief when arbitrary modification is permitted to any
of those.
Of course there is a separate 'security property' API that
currently puts limits of its own on modification of those
properties. Will that still exist, and will there be some
form of control on modification?
Regards,
Chapman Flack
