On Tue, Apr 26, 2022 at 4:47 AM Alan Bateman <alan.bate...@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
