For most Java developers, and Jvm users, it means that all Java
bytecodes need to be audited and trusted, to be fair OpenJDK provide
flight recorder and other tools. The drawback of this approach, is that
Java allows dynamic code downloads, attackers will attempt to introduce
gadgets, or injections into data consumed by Java programs, to gain
control of the Jvm. If you have sensitive data, such as certificates,
or ldap passwords, well, once an attacker gains access to one jvm in the
network, it provides the opportunity to gain access to sensitive data
and other network resources also. 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. Over the last decade or so, the Java trusted
platform was allowed to grow too large, and there were no permission
checks on deserialization, or xml parsing, which would have prevented
many such attacks, by allowing authorization decisions, based on the
authentication of data sources (provided they haven't been compromised).
In our software, we authenticate, then we dynamically grant permissions
based on least privilege principles (and dynamically revoke them when no
longer needed), we allow dynamic code downloads for dynamic services,
our software is very dynamic, you can have a service wrapped with a
JavaFX front end, and multiple services might be combined together for
form a dynamic system, that's continually evolving, replacing and
updating itself. We can do this securely now, but without
authorization, it falls apart, there are no restrictions and anyone who
is authenticated will have free access to everything. The people who
think we can do these things without an authorization layer, are
thinking of more traditional uses for Java, things that are static, no
dynamic code, all code is audited and trusted, then deployed.
But I digress and I guess it doesn't matter, there are no upcoming
features in OpenJDK that would tempt me to trade off security. Java has
been good enough for a long time, I guess the biggest thing will be
maintaining security and being able to continue on LTS would have been
nice. SM is still here for now, so we will be able to continue testing
and reporting bugs with OpenJDK, but once SM is removed, then that's
when we will be forced to stop upgrading. We've spent a lot of time
investigating our options, this is the way it has to be. We've run
with a SecurityManager for over two decades now, we solved performance
and usability issues, it's served us well and will continue to do so for
many years to come.
--
Regards,
Peter
On 19/06/2023 8:42 am, c...@anastigmatix.net wrote:
On 2023-06-18 08:15, Alan Bateman wrote:
Once the SM operating mode goes away then I would expect most usages
of privileged actions in the JDK can be removed. Leaving them for an
"authorization layer" to instrument would be misleading. Existing
usages will quickly bit rot. It would also be a tax on all future
features and all ongoing maintenance.
Perhaps it would be more feasible to look at some lower-hanging
fruit, such as making sure all file accesses go through the default
filesystem implementation (once that is imposed at startup, of course),
sockets can be controlled with socket factories, similarly for
processes, and so on.
Is the intention to have all system properties (even those that
contain critical platform information) be writable as a free-for-all,
or will there be some means to limit writing of those?
Regards,
Chapman Flack
