Hello Reinier,
Thanks for the feedback on the JEP. If I read your message correctly,
you seem to be primarily concerned with logging and/or restricting
access to file and network operations.
In my personal view, some of the examples you present that do somewhat
sketchy things are probably not a good idea to put in production. There
should be additional audits and reviews of code, and code that is not
widely used should be eyed with extra suspicion. It may not be quite the
same as running untrusted code, but it seems quite near it.
It doesn't seem realistic to keep the SecurityManager API and possibly a
lot more of related APIs supported for this limited use case. Also if
you remove the access control and policy infrastructure from the JDK,
then you are responsible for the policy, determining what code is making
the check, whether it is trusted or not, etc. That is difficult to
implement safely. My guess is that it would become too hard to use, or
too hard to implement safely, and would become rarely used (like the
Security Manager).
That said, I think it is worth exploring (in this JEP) or another JEP
ways that we might think about that could help provide DiD protection
for network and file access. This is an opportunity to look at the
problem with a fresh set of eyes, w/o the existing complicated
infrastructure and APIs that encompass the Security Manager.
Thanks,
Sean
On 4/15/21 9:29 PM, Reinier Zwitserloot wrote:
One useful thing that you can do with SecurityManager, which would be
impossible if it is removed, and which isn't described in the 'specific
narrow use cases' section:
Monitoring and restriction of, specifically, third party libraries.
99 out of a 100 modern java projects have a rather long list of
dependencies, and most of those dependencies have a limited and specific
intent. "This library reads EXIM data from a JPG". "This library
marshals JSON into java POJOs". "This library makes QR code PNGs".
As an app programmer I want to monitor, and optionally restrict what
these libraries can do. I can have an app that does (and is intended to)
make network connections all the time, but as part of doing the job I
wrote it for, it may be generating some QR PNGs. If the _QR generator
library_ is making network calls? I want to know, and I probably want to
stop it from happening.
SecurityManager can do that. I don't know of a good way to take care of
this without it, and it is not (currently) described in JEP411. I can't
use OS-level monitoring, because the OS has no awareness of modules /
packages / classnames, so I can't tell it to accept without log or
warning any network access done by the parts of my application that are
supposed to do this, but that I _do_ want it to log, warn, or halt any
attempt by that QR generator library to hit the network.
The original intent of SecurityManager was clearly to allow you to run
untrusted code on a VM (the 'applet' use case), but this is somewhat
different: It's not so much about attempting to secure presumably
malicious code in a library or applet, but instead about attempting to
secure against operations that ordinary java code may do, but which you
simply aren't expecting from some specific library.
Some real-world and/or highly plausible examples:
* An XML parser library may make network calls or open files on disk due
to e.g. XXE shenanigans: See
https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing
<https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing>
– this isn't just plausible, we have plenty of proof that this has
caused significant security breaches multiple times in XML's history. A
SecurityManager that monitors (or outright denies) specifically the
network and disk access from an XML parser library would have meant XXE
attacks could never have happened.
* Some twitter library may be invoking a relative-pathed `cmd.exe` in
order to retrieve some system info from windows that cannot be obtained
with any of the core java libraries. Perhaps to check if the twitter
desktop client is installed (the authors of the library may well be
unaware of the new ProcessInfo API). No doubt a scan of all java-tagged
projects on github finds rather a lot of libraries that
Runtime.exec("cmd.exe") for some unexpected, non-malicious purpose.
Nevertheless, ProcessBuilder does apply $PATH processing and a system
operator may not be willing to accept invokes to a relative path that
can be trivially hijacked if some directory in the PATH is compromised,
especially if the programming team that uses the library wasn't
expecting it to do so. A SecurityManager can monitor this and even stop
it from happening.
* Any library could have the bright idea to 'phone home' and make a
network call simply to give the library author some idea of how
widespread their library is used. This could have an entirely innocuous
purpose: The library author thought it'd be a cool idea to have a live
map of the planet on their website, with a little animated blip every
time their library is used to, say, parse some JSON. SecurityManager is
the simplest way to spot this and stop it.
I don't think SecurityManager is necessarily fantastic at stopping
_intentionally malicious behaviour_ by a library written by
untrustworthy charlatans (even though that was its original intent).
But, it does a great job at stopping a misunderstanding between a
library author and the user of said library, such as the rather
plausible scenarios I just described.
Modern security practices put a lot of focus on monitoring;
SecurityManager can do that too: A SecurityManager is not obligated to
deal with e.g. a notification that some code is attempting to open a
file by throwing SecurityException - they can also simply log or notify
somebody that it is happening and allow it. They could check if the
caller is in a subset of 'blessed' code that has been checked by the dev
team and has sign-off that it is allowed to do it. They could simply do
a quick echo in dev-mode only, just so developers are aware whilst
running tests that some library is doing things that have potential
security implications and open potential surface area for a breach.
I'm not sure if the file-based configuration of the security manager
(policy files) needs to be kept around to enable this use case, but the
basic infrastructure, and almost all of the various `check` methods in
java.lang.SecurityManager have plausible scenarios where an application
may want to monitor or deny what it triggers on when a library is doing
it that you don't want it to or did not expect to.
--Reinier Zwitserloot
