> 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.press...@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.mul...@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 > >
