JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

Do you regularly use the Security Manager to sandbox your own dependencies and find it convenient and effective
— in which case, could you please describe your practice concretely so that it would be possible to consider 
alternatives — or are you saying that you can *envision* such a powerful use-case? The desire to remove the 
Security Manager does not stem from its theoretical utility, which is absolutely amazing, but from its practical
utility, which years of experience have found to be less than amazing after all, and probably too low to justify 
its burdensome cost.

As to monitoring application activity, suspicious or otherwise, JFR is the component for that, and could be 
effective for the monitoring use-case you describe.

— Ron


> On 17 Apr 2021, at 15:18, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> 
> > Ron wrote:
> 
> > I think it’s worth adding that treating libraries as untrusted code is unworkable over the long run
> 
> Well, define 'untrusted'.
> 
> If you mean: "untrusted" as in it may well contain code explicitly designed to compromise our internal security, put there for malicious purposes by someone who is looking to infiltrate your software, systems, data, or clients – then, yes, I agree. Don't run libraries that may be compromised, even if you have registered a SecurityManager.
> 
> But if you mean "untrusted" as in: I did not personally check the full source code of the entire library, and it may be doing things _not_ with malicious intent, but nevertheless something that opens up additional attack surface that I wasn't expecting and need to update my internal security policies accordingly (or outright stop the library from doing it): Then I disagree. Why would it be 'unworkable' to treat libraries this way? I'd say rather the opposite: There will always be misunderstandings between the user of a library and the author of one of what and how it works.
> 
> There's a bit of community interaction with such things: If, say, the ZXING library (google's QR code generator stuff) ends advertising itself as 'makes QR code images', but is implemented as a light wrapper around https://charts.google.com?qr, then I expect the community to make a bit of a stink on social media about this, but the community cannot necessarily be trusted upon to take that first step quickly (of figuring out a library is doing things that cause one to raise one's eyebrow). There is ample historic context for this, such as the amount of time it took to find heartbleed. Monitoring a library for network access would let you figure out, quickly, that ZXING is not doing what you thought it did.
> 
> NB: Just to be clear, zxing _does not_ make any network calls. The library generates PNGs with QR codes as you would expect. But it makes for a plausible hypothetical, I think.
> 
>  --Reinier Zwitserloot
> 
> 
> On Fri, 16 Apr 2021 at 23:28, Ron Pressler <ron.pressler at oracle.com> wrote:
> 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
>