A possible JEP to replace SecurityManager after JEP 411

[Bernd Eckenfels]

Hello,

I dont agree with the statement that this can be solved on higher level. (Unless higher level means move away from existing architectures which is perfectly fine for some workloads but not for all)

IMHO Infrastructure to enforce on lower level is needed either for traditional sandboxing (which suddenly java is no longer a fan of - and at the same time wasm and native sandboxing makes a lot of ground with this feature).

Some instrumentation might be possible, but for traditional APIs with files, sockets and processes it looks much more convenient to have callbacks/permission checks like before (or a bit nicer with typed APIs like proposed here).

One point however pro new security concepts: if we had better integration in OS and Hypervisor, it might really be better to use different methods. Like having suid on thread context, allowing security context, dropping OS permissions, chroot/jail, modifying and inheriting access tokens, sharing memory with virtual machine or even deploying in sgx.. but not much of that (besides containers) is available of that as of now with Java.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Alan Bateman <Alan.Bateman at oracle.com>
Gesendet: Tuesday, April 26, 2022 10:28:57 AM
An: David Lloyd <david.lloyd at redhat.com>
Cc: OpenJDK Security <security-dev at openjdk.java.net>
Betreff: Re: A possible JEP to replace SecurityManager after JEP 411

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. 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. No thanks!

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.

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.

-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8155659
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220426/eca1e50c/attachment.htm>