On 18/05/2021 8:49 pm, Ron Pressler wrote:
On 18 May 2021, at 03:39, Peter Firmstone <peter.firmst...@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.
