On 9/2/21 9:42 AM, Doyle, James wrote:
Hi Sean,
Thanks for your response!
I re-checked the "Future Work" section of https://openjdk.java.net/jeps/411 and see the
"Monitoring access to resources" use case / enhancement you were referring to.
The enhancement as worded focuses on monitoring the operations and seems ambiguous about
whether blocking the operations is in scope ("while not necessarily restricting
these operations"). Can I suggest updating the wording a little to be clearer that
having the ability to block the operations is part of that use case?
Good point, although JFR is really a better solution for monitoring. In
recent releases, we have added more security-specific events to JFR
which help monitor TLS connections, certificates, deserialization, etc
so we should continue to explore this area more to see if it can provide
more security events, such as network/file access, etc.
So I would like to leave that one as-is. The "Blocking System::exit"
bullet should be expanded to potentially include other operations such
as file/network access.
Also, one of the things that's been helpful with Security Manager
permission-based policies today, is the ability to base decisions about those
operations on a whitelist of what's allowed for a given application, and that
the resources in that whitelist can be fine-grained (specific DNS names, file
paths, ports, etc). Could that aspect be captured in the wording of that use
case? In other words, a feature for monitoring and blocking operations would
be helpful if it could act not just as a blacklist of forbidden operations, but
a whitelist of allowed operations and resources at a fine-grained level.
So one point that should be made clear is that we don't intend to
replace the current Policy API and policy file implementation, etc. If
we go down this route, it will be up to the application to decide if a
particular operation should be blocked or not based on its own policies.
The JDK will no longer be a Policy Decision Point.
--Sean
Thanks,
Jim Doyle
-----Original Message-----
Date: Wed, 1 Sep 2021 15:03:22 -0400
From: Sean Mullan <sean.mul...@oracle.com>
To: security-dev@openjdk.java.net
Subject: Re: JEP 411 - use cases
Message-ID: <076900c6-5141-a3ca-6f3d-88416f84b...@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi James,
On 9/1/21 11:48 AM, Doyle, James wrote:
Hi,
Earlier this summer, our organization became aware of JEP-411 and the
plan to remove Security Manager in the future, and I?d like to add our
perspective to the use case / adoption aspect.
We deploy and manage a number of server-side Java applications, both
developed in-house and from vendors, and currently use Java Security
Manager to provide an extra layer of security around the server
application code.? Enabling Security Manager in the server application
JVM provides an additional means to defend against malicious
users/clients exploiting vulnerabilities (in our application code or
third-party code) to access the host OS in ways the individual JVM and
application are not intended to act.? The fine-grained permission
model is very useful for giving the application code the least
privilege needed for its specific function.? The permissions give us a
way to use a deny-by-default model and require a whitelist of the
files, directories, hosts, ports, URLs, etc. that each application
actually needs.? Our organization operates under compliance oversight,
and the Security Manager policy for our applications provides one of
the controls we use to insure a secure environment.? We?re worried
about the impact to these controls should Security Manager be removed.
Is the low adoption rate cited in the JEP (?After decades of
maintaining the Security Manager but seeing very little usage??)
anecdotal, or has it been measured somehow as part of proposing and
implementing the JEP?
What qualifies as ?low? or ?little??
This is based on various pieces of data accumulated over the years such as
incoming bug reports, surveys, external papers/studies of the SM, source code
repositories, product searches, difficulties using the SM, declining usage on
the client, etc.
Is the use case above one that the OpenJDK team is considering, to
make sure workable alternatives are available before removing Security Manager?
As described in the Futures section of the JEP, we are looking at some
alternatives for certain use cases. One of those is to potentially add a
mechanism that allows applications to monitor and optionally block certain
operations. The common use case listed in the JEP is blocking System.exit, but
some others have requested being able to monitor and/or block file/network
access. These and other alternatives need more discussion, but this is the list
where it will be discussed.
Some of our Security Manager usage is via Java EE / Jakarta EE
Security Manager permissions, and within that set, some apps
specifically use WildFly Security Manager.? Will the removal of
Security Manager from OpenJDK make related implementations like
WildFly Security Manager impossible to maintain as-is?? Will the
removal of Security Manager make users dependent on vendor-specific
implementations like WildFly Security Manager and unable to freely
move between Java EE / Jakarta EE implementations?
This is probably a question that is best answered by those that work on or
support WildFly.
--Sean
------------------------------
