On 22 Apr 2021, at 18:27, Reinier Zwitserloot
<[email protected]<mailto:[email protected]>> wrote:
For example, I may want to restrict access to the 'logs' directory. I can't
restrict it at the OS level (because the JVM does need to write the log files,
of course), at best I can restrict it at the module / package / code line
level, allowing the log framework write-only access, and deny it everywhere
else.
The problem at hand ("I want to treat my log dir as unreadable and unwriteable
to my own process, except for logging code, which should be allowed to write")
cannot be address with a 'configure the library' solution, unless the java
(new) files API grows a whole bunch of methods to redefine such things, and/or
to try to shove into a custom FileSystem implementation some code that does
stack trace introspection to try to make this happen.... and that still doesn't
address the `java.io.File` API.
--Reinier Zwitserloot
The problem is that this is not doable with the Security Manager, either,
except in theory. That the
Security Manager can do this *in principle* (depending on correct use of
doPrivileged) is not in dispute.
But experience over they years has shown that people, *in practice* aren’t able
to get Security Manager
to do that correctly; all the SM does is get people to *think* they can do it
(see http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf).
Such an approach to security based on a highly-flexible sandbox is,
empirically, not secure regardless of how
much we’d like it to work; Security Manager was designed so elaborately,
because back then, when the approach
was new, people believed it could work. But having gained a couple of decades’
worth of experience with
software security and various approaches to it, we now that, perhaps
disappointingly, it just doesn’t work.
In fact, it is worse than just not working — it’s insecure while giving a false
sense of security.
— Ron
