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

[Ron Pressler]

> On 18 May 2021, at 12:27, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
> 
> 
> However I disagree that the Principle of least privilege is wrong headed, I think you've been discussing sandbox concepts with the experts and they're going to tell you that's a bad idea.  But the two aren't the same, one is access control, the other is attempted complete leak proof isolation,  which is a very difficult thing to do that grows exponentially with your API surface area, I'm sure in years to come crackers will find vulnerabilities in VM's too. Sandboxing would work if you removed most of the library code and features and limited memory and threads, but I don't think anyone is seriously considering that.  Java for applets should have been it's own stripped down limited JVM.

When you say the “principle of least privilege” you seem to imply that it is at *all* cost. Many believe that
the attempt to assign different privileges to different *pieces of code* (not different people) is not effective
from a cost/benefit perspective. In other words, the effort would have a bigger impact on security if directed
elsewhere. After all, the same principle would imply that we’d need to afford different permissions at a method
granularity rather than class granularity.

> 
> What sort of cost, you mean development cost, the cost of understanding doPrivileged?

Both, but mostly the former.

> 
> At least to me, it's just a simple lambda expression, it's not difficult.  It think people are making this more complex than it needs to be due to a proliferation of Permissions, but even that I manage with tooling.

There’s no point to argue over this. It’s been tried for a couple of decades, people don’t want it, experts say it’s 
not cost-effective, no popular platform after Java and .NET has chosen to invest in it, and .NET has dropped it already.
Even if you convinced me that the effort of attempting to afford different permissions to different code in the same 
process was an effective use of resources, if you could have changed the habits of millions of developers you would 
have done it by now. You can carry on the argument over whether this is a good or bad idea on security forums and at 
security conferences, but that it didn’t pan out, adoption-wise, in practice is an empirical fact (that it's worked 
great *for you* is completely irrelevant). Even good ideas can fail to gain traction, and we shouldn’t throw good money 
after bad.

> 
> But it's such a shame to lose access control as collateral damage.

Most applications that do access control today do not use the Security Manager for that. When you say “access control” 
you mean something very specific, which is not what others mean when they say access control. In particular, even doAs 
is proposed to remain.


— Ron