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
