PrivilegedAction et al and JEP411

[Peter Firmstone]

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, chap at 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