A possible JEP to replace SecurityManager after JEP 411

Tue Apr 26 10:11:53 UTC 2022

Just to add to the discussion some more, as I understand it the new (Graal based?) multi language environment running inside a Oracle database is exactly what others want to do here: multimtenant untrusted code execution inside a bigger application.

There are a number of complications here, first of all it’s not the OpenJDK launcher/runtime and secondly it gets into native and also GPL territory, so that it’s unlike many but Oracle will be able to do such a solution. Under this light removing the SM hooks makes the situation even more problematic.

Gruss
Bernd

--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Peter Firmstone <peter.firmstone at zeus.net.au>
Gesendet: Tuesday, April 26, 2022 11:06:16 AM
An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: A possible JEP to replace SecurityManager after JEP 411

On 26/04/2022 6:28 pm, Alan Bateman 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. 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!

What about ensuring that all network access occurs through a single
location that we can instrument?

It would be nice to leave AccessController calls in place, oh well, such
is life.

>
> 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.

Yes, we went to a lot of trouble to ensure context is preserved through
executors and other thread calls, for executors, it was simple enough to
decorate a Callable.   However this is successful, in that our
RemoteEvent's and Event listeners use the preserved AccessControlContext
to establish and authenticate secure connections.

>
> 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.

Yes, I have also come across this problem, I use a thread local to
detect the recursion, in try finally blocks.

https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java#L347

One must also be aware of class loading, to ensure necessary classes are
loaded at the right time.

The following is an example of a complex issue, which was solved using
immutability, by avoiding shared state between threads and avoiding
blocking where possible.   Java's PermissionCollection implementations
are a minefield of synchronization, so we thread confined
PermissionCollection.   We avoided caching permission check results as
Java's policy cache is a huge performance killer.  There is also the
issue of DNS calls made in URL and URLClassLoader, so we fixed those
issues too.  Instead of relying on DNS we use RFC3986 and RFC5952
normalization.   The performance difference as you might imagine by
removing blocking network calls and replacing it with immutable
normalized forms was huge.

https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java#L265

https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java

>
> -Alan
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8155659

It's just such a shame that we achieved so much and OpenJDK is pulling
the rug from underneath us.

Regards,

Peter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220426/c16469ac/attachment.htm>