[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

[Ron Pressler]

> 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.

> 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