<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div dir="ltr">
<div style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" dir="ltr">
Hello,</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">
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)</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">
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).</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">
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).</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">
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.</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 id="ms-outlook-mobile-signature">
<div style="direction:ltr">-- </div>
<div style="direction:ltr">http://bernd.eckenfels.net</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 Alan Bateman <Alan.Bateman@oracle.com><br>
<b>Gesendet:</b> Tuesday, April 26, 2022 10:28:57 AM<br>
<b>An:</b> David Lloyd <david.lloyd@redhat.com><br>
<b>Cc:</b> OpenJDK Security <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">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 tax <br>
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>
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>
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 issues. <br>
JDK-8155659 [1] is one report that comes to mind.<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>
</div>
</span></font></div>
</body>
</html>