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

[Ron Pressler]

> On 21 May 2021, at 04:55, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
> 
> 
> Yes everything is a compromise and there are trade-offs.   The way I see it, the cheapest way to maintain security is to find others who share a common pain point is to maintain a copy of OpenJDK  focused on security.   We can audit upstream changes and add them later, with the security cost penalty, without throwing out the huge amount of effort performed by JDK developers over the years, there's no way we can re-implement it economically, so this appears the most sensible option.
> 

That may be the way you see it, but I think you have to accept that many security experts don’t think
that focusing on the Security Manager and focusing on security are the same thing. We want to remove the 
SM *because* we want to focus on security measures that will have a larger impact in the real world. Even 
if you think that the SM is the best path to Java security you must accept that others do not, and that 
even if we’re misguided, we’re doing this because we believe it will help improve security, and that the 
SM harms it. So if you want to maintain the Security Manager in the JDK and ecosystem libraries, you can 
say so, but saying that that is “focusing on security” is a mischaracterisation because it depends on
assertions that you know are controversial at the very least.

> 
> These are just opinions, it's nice to have them, but they're not helping.   I think you'll find usages of SecurityManager api's are far more widespread than your opinion suggests, but that's just my opinion too lol.

I guess you could say they’re my opinions because there is no conclusive proof, but they are based
on empirical data. At least you should scan GitHub and Maven Central. That few libraries are properly 
instrumented is yet another piece of evidence. This isn’t conclusive, and that is why we’re discussing
this here in an attempt to collect more information, but we have done our homework.

> 
> Yes, I think we should keep it simple, and keep calling it the principle of least privilege, to avoid confusion, it's very beneficial for reducing the consequences of perimeter security failure, even if your experts think otherwise.

It is absolutely not the principle of least privilege, which was formed long before the Security Manager
existed and is applied for all software, even that not written in Java (the last remaining mainstream platform 
with a mechanism that assigns permissions on a per-class basis). It is true that the SM allows smaller
units than the process or the user for the purpose of permissions, but if you think the principle means that
least privilege must be assigned at the smallest unit theoretically possible, then the Security Manager
doesn’t do that, and if you think it’s a matter of picking an effective unit granularity, then I believe
other measures apply it more effectively.

But there is something you keep missing here, and that is that the question of whether or not there are
circumstances in which the Security Manager will stop an attack — and there are — is irrelevant to the 
question of whether it is an effective security mechanism. That an elaborate trap will stop intruders who 
happen to try to enter my property at a specific spot doesn’t make it an effective mechanism, because a 
fence surrounding my property will stop even more intruders and do it more cheaply. “Beneficial” for us 
doesn’t mean “might help”, but what is the amount of total help offered per unit cost *compared to all 
other mechanisms’ benefit per cost*. In other words, we ask ourselves, is the Security Manager the best 
thing to invest in if we want security compared to all other things we can invest in?

If your codebase is trusted, then what you want to defend against are accidental vulnerabilities, 
i.e. bugs. Suppose your application requires permissions X and Y to run. What the Security Manager 
allows you is to notice that your application is made of two components, A and B, and after analysis 
conclude that while A requires permissions X and Y, B requires only X, and to grant only X to B. This 
can preemptively prevent exploits in your application that: 1. target component B and 2. require permission 
X. How much is preventing this particular scenario worth and are there ways to prevent more?

Just as the Security Manager doesn’t find it a good tradeoff to separate A and B at a method granularity, 
we don’t think it’s a good tradeoff to separate them at a class granularity. Grant your entire process 
permissions X and Y, and monitor it. Modern detection methods can automatically detect an unusual behaviour 
if B attempts Y and alert you to fix the bug, and we prefer investing the very high effort of maintaining
the SM at reducing the attack surface area of the JDK overall, reducing the chance of attacks on either A 
or B, whether they require permissions X or Y, and also being always on for everyone. We believe this buys 
us *more* security for the same cost, and that is why newer Java versions will be more secure than previous 
ones.

— Ron