JEP411: Missing use-case: Monitoring / restricting libraries

[David Black]

Hi Ron

On Thu, 13 May 2021 at 20:22, Ron Pressler <ron.pressler at oracle.com> wrote:
>
>
>
> > On 13 May 2021, at 03:11, David Black <dblack at atlassian.com> wrote:
> >
> >
> > This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
>
> This is an important point we’re trying to get across. The very reason the Security Manager was made this
> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
> experience have shown us that *in practice* this is not the case, certainly not when you look at the
> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
> the job done, but actually use it incorrectly, providing the illusion of security without actual security.

Agreed, but if you don't have this level of introspection/detail how
do you propose to, at least partially, mitigating bug classes such as
SSRF?

> > Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager).
>
>
> We’re talking about a situation where *all* the classes running in your application are trusted,
> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
> Can you explain why you believe this mechanism, that treats different classes differently is the best
> way to improve security?

Because it allows for restrictions to be placed upon "trusted"[0]
classes so as to offer some mitigation against classes of bugs such as
SSRF. You can also use a security manager to monitor for potential
policy implementation issues & make adjustments. Specifically for
SSRF, if you want to mitigate the issue you need to ensure that
network connections being made respect proxy settings but also allow
support for certain code paths bypassing proxy settings to access
potentially sensitive network locations (e.g. cloud metadata
resources) this can result in mistakes in configuration occurring and
or finding libraries/classes that ignore proxy configuration. You may
be thinking "oh but surely no library/class would have proxy
problems?" well that answer is "yes they can and do". For example,
https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
9 but has not yet been fixed in java 8[2]. In a similar fashion,
OkHttp before version 3.5.0 could also fallback back to a direct
connection[3]. So having a "belt and braces", prox(y|ies) and a
security manager, approach is valuable.


[0] "Trusted" classes are not immune to security issues
[1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
[2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
&  https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1180
[3] https://square.github.io/okhttp/changelog_3x/#version-350