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

[Peter Firmstone]

On 18/05/2021 8:49 pm, Ron Pressler wrote:
>
>> On 18 May 2021, at 03:39, Peter Firmstone <peter.firmstone at zeus.net.au> wrote:
>>
>>
>> Is it also possible to consider directing file access and network access through single points of access?   This will simplify the process so we don't need to scour the entire codebase for usages.
>>
> Of all your suggestions, I think this is the one that will be seriously considered from a cost/benefit
> perspective, although probably not as part of this JEP.


Thank you ,appreciated.


>
>> What about doPrivileged calls?   Will they remain in existing Java library code, so we can utilise them?  To avoid viral permission propagation?
> Doubtful. That is where much of the cost is, and it would mean investing significant resources into supporting
> a use-case that what seems like the vast majority of security experts think is a wrong-headed approach, for the sake
> of the few who disagree. Even as an additional mechanism that might, maybe, block exploiting some vulnerability as a
> result of some particular bug in some cases, sometimes, maybe, the high cost doesn’t justify what we believe is the
> extra defence gained compared to the gain of such an effort directed elsewhere.
>
> — Ron

Oh well, there was no harm in asking.

I agree that sandboxing is the wrong approach, it's unfortunate that 
this wasn't seen as a potential issue in the early days. It's similar 
with Java Serialization, if they tried to do less initially it would 
have been much better, but they pushed to envelope too far.

But I'm pretty sure we've moved on from discussing sandboxes, no one is 
claiming that as their use case.

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.

Our problem is we will need to grant remote third party's AllPermission 
because they are not represented as a Subject based ProtectionDomain in 
the JVM, but then we could implement some sort of analysis that removes 
their ability to connect at all if they violate policy.

But this doesn't seem very workable.  Thankfully we have a very good, 
functional and highly scalable solution available now.

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

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.

AccessController.doPrivileged uses 1.3% of CPU time in my system, and 
I'm sure I use it far more than many, so I don't think your talking 
about performance.

Thankfully access control is much simpler today than say programming 
concurrently, but I try to do both well.   I truly don't find it 
difficult to use, but then I've built a bunch of tools that make it useable.

But I get that JVM developers have suffered a lot of pain with Security 
vulnerabilities due to Java Serialization and the Sandbox and just the 
mention of SecurityManager is received negatively.

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

Thanks again for spending the time to discuss.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.