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

[Peter Firmstone]

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.