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

[Peter Firmstone]

On 18/05/2021 10:09 pm, Ron Pressler wrote:
>
>> 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.


No, actually to date, it's been a very affordable option, probably 
because the burden has been on Openjdk developers to date, to which I'm 
very grateful.   It doesn't impact performance and it allows me to 
reduce the attack surface of my programs, especially in regard to 
dependencies.


https://debricked.com/blog/2021/01/02/vulnerabilities-in-dependencies/


>> What sort of cost, you mean development cost, the cost of understanding doPrivileged?
> Both, but mostly the former.


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.


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


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.

You've probably have never used it, so you don't really understand it, I 
can't argue with ignorance and you can't understand the benefit, if you 
are only asking others for their opinions, you are likely surrounded by 
people with the same opinion, so you're suffering from confirmation bias 
without any practical application, as is anyone else that doesn't use it.

https://berteig.com/coaching/confirmation-bias/


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


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.

-- 
Regards,
  
Peter Firmstone