I would say that trying to mitigate attacks on vulnerabilities in trusted code based on specific code paths is not recommended. You’re trying to preemptively defend agains something complex — a security bug — with another complex mechanism. Even if you do happen to defend against a particular attack attempt due to a bug that happens to be in the “less trusted” code rather than in the more trusted code, the cost/benefit to this approach is not very attractive, in my opinion.
I think it is easier and simpler (and so more secure) to not differentiate codepaths in the same process, grant whatever minimal privileges are required to the entire process with more watertight mechanisms than the SM, and then actively monitor it — say, with streaming JFR events, which will be made richer, and already do expose the stack trace — for suspicious activity. If a bug is found — fix it. If your application clearly has more trusted/less exposed components and less trusted/less exposed ones, and you feel that they must be separated for security reasons, consider running them in different processes. Process isolation is a more secure, better studied, and better supported security mechanism than the Security Manager. — Ron > On 17 May 2021, at 03:11, David Black <dbl...@atlassian.com> wrote: > > Hi Ron > > On Thu, 13 May 2021 at 20:22, Ron Pressler <ron.press...@oracle.com> wrote: >> >> >> >>> On 13 May 2021, at 03:11, David Black <dbl...@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://urldefense.com/v3/__https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager__;!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PHR4-37A$ >>> ). >> >> >> 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://urldefense.com/v3/__https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java*L1180__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PCT2HmkQ$ > > [3] > https://urldefense.com/v3/__https://square.github.io/okhttp/changelog_3x/*version-350__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_OyQxtDiw$ >
