<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
On 22/05/2021 11:58, Bernd Eckenfels wrote:<br>
<blockquote type="cite" cite="mid:AM0PR03MB4145AD55C2F2AFE8FAB2BCA9FF289@AM0PR03MB4145.eurprd03.prod.outlook.com">
<div dir="ltr">
<div>
<div>
<div dir="ltr" data-ogsc="" style="">:
<div dir="ltr" style="color: rgb(0, 0, 0);
background-color: rgb(255, 255, 255);">
<br>
</div>
<div dir="ltr" style="color: rgb(0, 0, 0);
background-color: rgb(255, 255, 255);">
This whole discussion about using only secure libraries
really makes me wonder if you know the realities of
modern applications with hundreds of dependencies and
the state of those, like there is still no easy way to
limit XXE in upstream xerces. (Or Have you ever tried to
set FSP on a Transformer?), limit deserialisation,
restrict url handlers, impersonate Users (local and
remote filesystem), run chroot child’s or pass
credentials over named pipes. All mechanisms which are
easier to do in other programming environments. There is
a big hesitation to even offer those platform specific
features.</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
You've touched on a number of topics here, some of them quite far
away from JEP 411 but okay.<br>
<br>
I think the issues with deploying an applications with hundreds of
dependences and with a SM are well understood here. It tends to be
whack-a-mole because so many libraries were developed without any
consideration for the SM execution mode. The result is often
granting AllPermission to many libraries just to get something
working.<br>
<br>
XXE and secure XML processing is something that needs to be
decoupled from the SM. As the JEP lists, there is potential future
work to enable FSP by default. Now might be the time to bring up
usability and other issues with FSP as I think it will be tricky
transition to move to secure by default. I can't comment on Xerces
as the code maintained in OpenJDK has diverged quite a bit, esp.
with security features.<br>
<br>
There has been significant efforts to limit deserialization. JEP
415 is a candidate right now, as a follow from on JEP 290.<br>
<br>
If integration with native code and system calls is part of your
concern then looking at Project Panama's foreign function API as it
has made great strides in the last year or so. JEP 412 is targeted
to JDK 17 to continue the incubation of the API and trying it out
with code that uses named pipes would be great. JEP 380 added Unix
domain socket support in JDK 16 and that includes the ability to
obtain peer credentials, maybe that is close to what you are looking
for.<br>
<br>
-Alan<br>
</body>
</html>