JEP411: Missing use-case: Monitoring / restricting libraries

[Reinier Zwitserloot]

> Alan Bateman wrote:
> security features for XML processing can be controlled programmatically,
it doesn't require a security manager to do that.

Yes, it would be nice, and it is feasible, for XML parser libraries to gain
API calls to tell them to never hit the disk or the network to resolve
external entities.

However, that principle (of "Let the library itself grow configurable
options to restrict whatever you feel you want to restrict on a case by
case basis") does not generalize.

For example, I may want to restrict access to the 'logs' directory. I can't
restrict it at the OS level (because the JVM does need to write the log
files, of course), at best I can restrict it at the module / package / code
line level, allowing the log framework write-only access, and deny it
everywhere else.

The problem at hand ("I want to treat my log dir as unreadable and
unwriteable to my own process, except for logging code, which should be
allowed to write") cannot be address with a 'configure the library'
solution, unless the java (new) files API grows a whole bunch of methods to
redefine such things, and/or to try to shove into a custom FileSystem
implementation some code that does stack trace introspection to try to make
this happen.... and that still doesn't address the `java.io.File` API.

 --Reinier Zwitserloot


On Sat, 17 Apr 2021 at 16:54, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 16/04/2021 02:29, Reinier Zwitserloot wrote:
> > :
> >
> > * An XML parser library may make network calls or open files on disk
> > due to e.g. XXE shenanigans: See
> >
> https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing
> > <
> https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing>
>
> > – this isn't just plausible, we have plenty of proof that this has
> > caused significant security breaches multiple times in XML's history.
> > A SecurityManager that monitors (or outright denies) specifically the
> > network and disk access from an XML parser library would have meant
> > XXE attacks could never have happened.
> >
> The Security Developer's Guide has a good chapter on this topic [1] as
> there many configuration knobs to restrict or disable "external access"
> during XML processing. As things stand, running with a security manager
> enables FEATURE_SECURE_PROCESSING globally but that is unfortunate
> coupling and perhaps masks that the security features for XML processing
> can be controlled programmatically, it doesn't require a security
> manager to do that.
>
> -Alan
>
> [1]
>
> https://docs.oracle.com/en/java/javase/16/security/java-api-xml-processing-jaxp-security-guide.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20210422/4499660e/attachment.htm>