<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<div dir="ltr">
<div></div>
<div>
<div>
<div dir="ltr">
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
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
<span id="ms-outlook-ios-cursor"></span>execution inside a bigger application.</div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
<br>
</div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
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.</div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
<br>
</div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
Gruss</div>
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
Bernd</div>
</div>
</div>
<div id="ms-outlook-mobile-signature">
<div><br>
</div>
<div><br>
</div>
<div style="direction:ltr">-- </div>
<div style="direction:ltr">http://bernd.eckenfels.net</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> security-dev <security-dev-retn@openjdk.java.net> im Auftrag von Peter Firmstone <peter.firmstone@zeus.net.au><br>
<b>Gesendet:</b> Tuesday, April 26, 2022 11:06:16 AM<br>
<b>An:</b> security-dev@openjdk.java.net <security-dev@openjdk.java.net><br>
<b>Betreff:</b> Re: A possible JEP to replace SecurityManager after JEP 411</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
On 26/04/2022 6:28 pm, Alan Bateman wrote:<br>
> On 25/04/2022 13:53, David Lloyd wrote:<br>
>> Nothing in the proposal causes splitting or delegation of<br>
>> responsibilities. It is _only_ about preserving security checkpoints<br>
>> in the JDK, which *add* a layer of checks to what the container might<br>
>> already provide. Nothing is being subtracted, and thus I find it hard<br>
>> to accept that preserving these checks somehow reduces security<br>
>> overall.<br>
><br>
> "preserving security checkpoints in the JDK" suggests just leaving the <br>
> calls do AccessController.doPrivileged and <br>
> SecurityManager.checkPermission in place. That amounts to putting a <br>
> tax on every feature, every JEP, and all ongoing maintenance of the <br>
> platform. If there is refactoring or a change that forgets to insert a <br>
> checkPermission somewhere then we have a security issue and everything <br>
> that goes along with that. No thanks!<br>
<br>
What about ensuring that all network access occurs through a single <br>
location that we can instrument?<br>
<br>
It would be nice to leave AccessController calls in place, oh well, such <br>
is life.<br>
<br>
<br>
><br>
> I think Martin is right that hooking authorization libraries into low <br>
> level libraries isn't the right way to do this. Aside from the <br>
> complexity methods I would add that threads pools or any hand-off <br>
> between threads will typically break when the context is not carried.<br>
<br>
<br>
Yes, we went to a lot of trouble to ensure context is preserved through <br>
executors and other thread calls, for executors, it was simple enough to <br>
decorate a Callable. However this is successful, in that our <br>
RemoteEvent's and Event listeners use the preserved AccessControlContext <br>
to establish and authenticate secure connections.<br>
<br>
<br>
><br>
> One other point about authorization libraries wanting to hook into low <br>
> level code is that it's a minefield of potential issues with recursive <br>
> initialization, stack overflows and some really hard to diagnose <br>
> issues. JDK-8155659 [1] is one report that comes to mind.<br>
<br>
Yes, I have also come across this problem, I use a thread local to <br>
detect the recursion, in try finally blocks.<br>
<br>
<a href="https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java#L347">https://github.com/pfirmstone/JGDMS/blob/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java#L347</a><br>
<br>
One must also be aware of class loading, to ensure necessary classes are <br>
loaded at the right time.<br>
<br>
The following is an example of a complex issue, which was solved using <br>
immutability, by avoiding shared state between threads and avoiding <br>
blocking where possible. Java's PermissionCollection implementations <br>
are a minefield of synchronization, so we thread confined <br>
PermissionCollection. We avoided caching permission check results as <br>
Java's policy cache is a huge performance killer. There is also the <br>
issue of DNS calls made in URL and URLClassLoader, so we fixed those <br>
issues too. Instead of relying on DNS we use RFC3986 and RFC5952 <br>
normalization. The performance difference as you might imagine by <br>
removing blocking network calls and replacing it with immutable <br>
normalized forms was huge.<br>
<br>
<a href="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/c1edf5892306f24f8f97f459f499dec54984b08f/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java#L265</a><br>
<br>
<a href="https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java">https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java</a><br>
<br>
><br>
> -Alan<br>
><br>
> [1] <a href="https://bugs.openjdk.java.net/browse/JDK-8155659">https://bugs.openjdk.java.net/browse/JDK-8155659</a><br>
<br>
It's just such a shame that we achieved so much and OpenJDK is pulling <br>
the rug from underneath us.<br>
<br>
Regards,<br>
<br>
Peter.<br>
<br>
</div>
</span></font></div>
</body>
</html>