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
