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-r...@openjdk.java.net> im Auftrag von Alan Bateman <alan.bate...@oracle.com> Gesendet: Tuesday, April 26, 2022 10:28:57 AM An: David Lloyd <david.ll...@redhat.com> Cc: OpenJDK Security <security-dev@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
