A possible JEP to replace SecurityManager after JEP 411

[Peter Firmstone]

Well said, we're not trying to sandbox untrusted code.  We're simply 
trying to provide authorization controls on authenticated users and in 
my particular case, service proxy's.   It's well known the JVM can't 
handle untrusted code, nor does it have well designed defenses against 
parsing untrusted data, all these things happen to be bolted on 
afterthoughts.

Regards,

Peter.

On 26/04/2022 11:07 pm, David Lloyd wrote:
> 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).
>