A possible JEP to replace SecurityManager after JEP 411

[David Lloyd]

On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 25/04/2022 13:53, David Lloyd wrote:
> > Nothing in the proposal causes splitting or delegation of
> > responsibilities. It is _only_ about preserving security checkpoints
> > in the JDK, which *add* a layer of checks to what the container might
> > already provide. Nothing is being subtracted, and thus I find it hard
> > to accept that preserving these checks somehow reduces security
> > overall.
>
> "preserving security checkpoints in the JDK" suggests just leaving the
> calls do AccessController.doPrivileged and
> SecurityManager.checkPermission in place.

The proposal is clear that the JDK 'doPrivileged' calls would not be
necessary, and it is not necessary to exactly use `checkPermission`
depending on the approach taken. This might or might not counter your
argument, but as I said before, even if the proposal is rejected, it
should be rejected based on a fair and accurate evaluation of what is
proposed.

> That amounts to putting a tax
> on every feature, every JEP, and all ongoing maintenance of the
> platform. If there is refactoring or a change that forgets to insert a
> checkPermission somewhere then we have a security issue and everything
> that goes along with that.

Sure, if you continue to think of SecurityManager as a sandbox, then
every case where it is not a perfect sandbox can be a major security
issue. In real terms though, was SecurityManager ever _actually_
effective as a sandbox? It is certainly the case that few (if any) of
us who do systems and security programming in application servers and
containers at Red Hat have ever considered it so. Thus, the proposal
as given tries to reflect this reality by treating the SecurityManager
as exactly two things: firstly, a central point for any application or
library to be able to statically perform an authorization check
without needing to rely on any library other than the JDK itself; and
secondly, a mechanism by which certain operations performed by the JDK
can be authorized by the user.

The lack of an authorization check would therefore be less impactful
when considered from this perspective. Maybe a security issue, yes,
but not a sandbox escape because there _is_ no sandbox. It's not a
part of the contract anymore. In fact, part of the contract could even
be an _explicit admonition_ that missing checks in the JDK would be
considered bugs but not security issues. Even that would be better
than removing the whole thing; if doing X has an unacceptable cost,
let's stop doing X instead of getting rid of Y.

> I think Martin is right that hooking authorization libraries into low
> level libraries isn't the right way to do this. Aside from the
> complexity methods I would add that threads pools or any hand-off
> between threads will typically break when the context is not carried.

Propagation of security context is not a problem that needs a solution
in the JDK and is not a part of the proposal. It's generally already a
solved problem within containers, where this feature is intended to be
used, including cases where threads are created or tasks are
dispatched to thread pools, fork/join, etc. Thus the proposal
establishes that this is 100% the responsibility of the security
manager implementation.

> One other point about authorization libraries wanting to hook into low
> level code is that it's a minefield of potential issues with recursive
> initialization, stack overflows and some really hard to diagnose issues.
> JDK-8155659 [1] is one report that comes to mind.

It is up to the implementation to deal with recursive calls into the
security manager today (and we already do so to our own satisfaction),
and I don't see any reason why that wouldn't continue to be the case.
In my opinion, this would not be an issue that the JDK has to be
concerned about (other than maybe as a documentation issue).

-- 
- DML • he/him