> 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. > 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? — Ron
