JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

I think it’s worth adding that treating libraries as untrusted code is unworkable over the long run, as their set of permissions possibly 
needs to be reexamined with every update. On the other hand, JFR can serve as a mechanism for tracing application behaviour, which,
when streamed, can serve to raise alerts.

— Ron

> On 16 Apr 2021, at 22:02, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> 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