On 18/05/2021 4:10 pm, Alan Bateman wrote:
On 18/05/2021 03:39, Peter Firmstone wrote:
:
Yes, I realize that, it is my understanding that because this is a
security concern, it is not something the community is allowed to
provide support for at OpenJDK, hence my suggestion to Alan, to make
it possible for this to happen by changing the security level and
calling it an access control layer concern.
Sorry, I was too busy and didn't have time to reply to your previous
mail on this and the performance anomaly in Java 14.
I'm dubious about your suggestion. Every issue or report that Java has
a security bug has to be analyzed on the assumption that it may be a
vulnerability. Saying that SM bypass or a ninja move that disables the
SM is not a security concern would create a perception issue. It would
get lost in the discussion that the SM is rarely used in the way that
it was envisaged 20+ years ago. The other thing is that it wouldn't
remove the ongoing burden to insert/audit permission checks, check
that ACC are captured and used in the right places, and of course
testing as it's another execution mode.
-Alan.
Thanks Alan,
It's a perception issue, I understand, but we can fix that far less
painfully.
You could create a new parent class of SecurityManager that's more aptly
named, for example AccessAssistant, and deprecate SecurityManager for
removal.
That's actually pretty easy, even backport the new class to earlier
versions of Java, so libraries can eliminate usages of SecurityManager
sooner.
This would give us time to change our dependencies to the superclass,
and it eliminates the name perception issue.
"AccessAssistant, is only intended to assist with access control
measures to implement the principle of least privilege, while it may
reduce the impact of a security breach, it's not capable of preventing
it, therefore bugs in access decisions aren't given the same attention
as security bugs, as both users and code are trusted."
AccessController and AccessControlContext have functionality that we
depend on for access control and to obtain user credentials for
authentication.
Let the community manage it as an access control layer, when we find the
ACC has forgotten to be captured, we can fix it. When someone forgets
to capture the ACC, the thread cannot establish a secure connection, it
will get noticed and fixed, it alone cannot cause a security breach.
We use TLS connections, sanitize data, atomic failure, input validation
and authentication for security, we only use access controls and Policy
for limiting access of trusted users and code and to obtain user
credentials. Access control and POLP gets those boxes ticked and might
be the difference for choosing Java over another platform.
If people aren't defensively parsing their input, not using secure
connections and authentication and someone takes advantage of that, well
it's just too bad, it's their fault.
If someone is using trusted connections but there's a successful
phishing attack on user credentials, then the attacker can usually only
obtain what the user has access to, yes it is possible to perform a
privilege escalation attack, but the point is the breach has already
occurred, the security vulnerability is not access controls, it was the
authentication system failure.
Don't stress the performance anomaly, it hasn't regressed in later
versions and the standard Java Policy provider will mask it. You'll
only notice it when using a scalable policy provider. If I see it again
in any long term releases, I'll let you know. I suspect whatever
caused the problem was spotted and fixed already.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
