JEP411: Missing use-case: Monitoring / restricting libraries

[Reinier Zwitserloot]

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
– 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210416/e8648c88/attachment.htm>