JEP411: Missing use-case: Monitoring / restricting libraries

[Peter Firmstone]

Thanks Alan,

I understand the motivation.

The front line of security is authentication, privacy (encryption), 
verification and validation with failure atomicity.

SecurityManager is unfortunately named, giving the impression that it 
has responsibility for security.  In truth, it's ONLY an access decision 
tool, rather than a controller or manager.   It can have benefits for 
security, when employing the principle of least privilege, but it is not 
in and of itself a solution for system security, as you most rightly 
imply, it becomes an expensive game of whack-a-mole.

I think the problem is one of perception.

I would like to propose instead of deprecation, is that we simply 
document that security manager no longer performs it's original intended 
role, that it's role today is only to assist in access decisions.   Lets 
remove the concept of a SecurityManager sandbox, let's put in big bold 
friendly letters, "THIS IS NOT A SANDBOX, NOR SHOULD IT BE RELIED UPON 
TO SECURE YOUR SYSTEM, IT IS ONLY SUITABLE FOR ASSISTING IN ACCESS 
DECISIONS FOR TRUSTED USERS AND CODE"   And also explain why, ie the 
game of whack-a-mole.  Then a discussion of least privilege principles 
would be appropriate.

In your examples below, where someone has forgotten to check a 
permission, or preserve context across threads, these are not 
exploitable until the front line of defense fails.

Typically forgetting to preserve the context prevents a TLS connection 
from opening and it will be reported and fixed, but it is not a security 
risk, it just means you can't connect until it's fixed.

Often the failure to check a permission is benign, because the code is 
trusted, but it does provide a way to manage who has access to data and 
to monitor it.

Java Serialization shouldn't be used to process un-trusted data either, 
nor should it be used over an unencrypted connection, even with a 
whitelist, there is no guarantee of security, as it lacks validation 
failure atomicity.

So how about we lower the bar for reporting, such that a bug in access 
control is treated differently than bugs that truly threaten security?  
Lets make some rules around that so that when someone reports a bug, 
it's not escalated to a security bug if one of the front line defenses 
would prevent an untrusted party taking control of the jvm.

Create a new bug category called ACCESS CONTROL BUGS, still fix holes in 
access control when reported, but don't escalate it to a level of 
security that no one can see, instead, publish the bug and let people 
submit patches.  This will reduce the maintenance burden and cost.   We 
still want access control to function, but recognize its limitations.

At work in your typical corporate environment, users are given access to 
directory's and files using Kerberos / RBAC and are typically disallowed 
from installing an application on their computer and have to call up the 
IT help desk to have software installed, this is because your average 
user will install anything onto their computer to get things done.  The 
average user isn't a hacker, that's going to hack your systems.

Access control on Java should be treated similarly, I install this code, 
or authorize this user, on my JVM but I'm going to place some 
limitations on what they are allowed to do.  We are not expecting them 
to hack the system.

I found the type of bug you are talking about myself only recently:

https://github.com/pfirmstone/JGDMS/issues/125

Privileged methods and context are commonly used to establish TLS 
connections, so removing AccessControlContext and AccessController will 
break this code, when we already have the tools we need to establish TLS 
connections.

Save the work of writing new tools to replace existing functionality, 
document the existing, change how we respond and devote the resources to 
something more important.   That way our existing code should also 
remain functional, so it's win-win.

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


On 6/05/2021 9:48 pm, Alan Bateman wrote:
> On 06/05/2021 11:26, Peter Firmstone wrote:
>>
>> OpenJDK seems to have assumed that no one was using SecurityManager 
>> based on one research report.
>>
> I don't think this is right. Instead I would say that many of us have 
> rarely encountered deployments on the server-side that are using a 
> SecurityManager to enforce security as envisaged by the Java security 
> model. I've been at Java conferences where the sessions on this topic 
> had less than 10 people in the room. Most of the actual usages that 
> I've come across have been more like using the security manager as a 
> convenient way to intercept network and file access for the purposes 
> of logging or blocking. These usages may not have a need for 
> protection domains, stack walks, policy files and the other complexity 
> that comes with the security model.
>
> One thing that is missing from the discussions here is the cost and 
> tax that supporting the SM "operating mode" brings. Many of the big 
> features and all changes to security sensitive code must pay this tax. 
> If there is a bug, a missing checkPermission for example, then it gets 
> treated as security vulnerability at massive cost. Everything 
> asynchronous brings more complexity and effort to figure out where the 
> checks should be and whether an AccessControlContext needs to be 
> carried around. I look forward to the day where we can be like other 
> languages and runtimes that don't have to be concerned with this 
> complexity and optional way of running.
>
> Finally, just to point out again that this JEP is about deprecating 
> for removal in the future, it doesn't propose to remove the security 
> manager now. If it moves forward then it will probably be several 
> releases of degradation before it is removed. That gives time to 
> properly consider the use cases where the security manager is useful 
> today. Also if it is eventually removed, then anyone that really 
> depends on this world can continue to use supported releases for years 
> to come.
>
> -Alan