[External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

Alan Bateman Alan.Bateman at oracle.com
Sat May 22 18:56:17 UTC 2021


On 22/05/2021 11:58, Bernd Eckenfels wrote:
> :
>
> 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.
>
You've touched on a number of topics here, some of them quite far away 
from JEP 411 but okay.

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.

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.

There has been significant efforts to limit deserialization.  JEP 415 is 
a candidate right now, as a follow from on JEP 290.

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.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210522/06ee6bdd/attachment.htm>


More information about the security-dev mailing list