PrivilegedAction et al and JEP411
chap at anastigmatix.net
chap at anastigmatix.net
Mon Jun 19 12:28:01 UTC 2023
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
More information about the security-dev
mailing list