A possible JEP to replace SecurityManager after JEP 411

[Martin Balao]

David,

I understand the reasons behind seeing authorization checks at the runtime
layer as something that just adds, without any harm in the worst case (all
of this putting the maintenance cost and other arguments aside.)

My concern is more about the general security principles underpinning the
idea. We will probably agree that half-barriers are not barriers, and might
cause a false sense of security. If we have authorization checks at the
runtime level, they must be comprehensive, coherent and well-maintained.
Their availability suggests that mixing high-level checks with
runtime-level ones can be part of a good security design in modern
application development. For the reasons that we've been discussing, I'm
not convinced of that. And even when subtle, I prefer the runtime not to
make the suggestion. If you still want it, you can go ahead with
instrumentation; but it's clear that for the runtime developers that is a
workaround and not a desirable security design.

What I mean by splitting responsibility is that application developers can
use a mix of high and low level checks, at different layers, with more
complexity. As Sean said, letting the unauthorized user to move towards the
edge of the action is more risky. We can lose sight of workarounds and
holes with the additional attack surface and complexity that comes at a
lower layer. What I want to stress is the value of clarity, simplicity and
division of responsibilities as a general security principle.

Martin.-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220427/1028f417/attachment.htm>