JEP411: Missing use-case: Monitoring / restricting libraries
Peter Tribble
peter.tribble at gmail.com
Wed May 12 20:46:25 UTC 2021
On Thu, May 6, 2021 at 12:48 PM Alan Bateman <Alan.Bateman at oracle.com>
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.
>
We're (partly, at least) in that group. We can't block the access from
outside
the JVM (and we are containerized with restricted permissions already)
because
some accesses are legitimate - something outside the JVM doesn't know when
the JVM is executing a particular piece of code, so we toggle the Security
Manager
on and off depending on context.
And here's the thing; there isn't really anything in the proposal that
addresses this
use case, or offers an alternate way forward.
> 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.
>
I appreciate that there will be older versions we can run; the issue is
always
that there may be some external driver why we have to update - either to
gain
a critical feature, or because something else doesn't support the old
version.
I know I would feel a lot happier with this proposal and its implications
if the
consideration of those use cases where the security manager is useful today
was more fully fleshed out.
Thanks,
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210512/78d58354/attachment.htm>
More information about the security-dev
mailing list