JEP411: Missing use-case: Monitoring / restricting libraries
Sean Mullan
sean.mullan at oracle.com
Thu May 13 16:15:06 UTC 2021
On 5/12/21 5:41 PM, Peter Tribble wrote:
> Let me give a concrete example:
>
> Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> We know exactly where the files are installed, so wish to allow the
> rendering routine access
> to the fonts it will need. But not to any other files, and not
> (normally) to network resources at
> all. Note that we trust the code, but not necessarily the document it's
> parsing. (Although the
> document itself may be perfectly well formed - document formats often
> allow embedding
> references to 3rd-party objects, undesirable as that may be.)
>
> There are a range of such issues in document parsing and rendering. And
> unfortunately, the
> good libraries for this task are proprietary so we can't modify them to
> apply the restrictions
> we're after. The (server-side) application does need access to files and
> network resources at
> other times; it's only when it goes into the rendering step that we lock
> it down, and unlock it
> once done.
I know very little about this area, but I would think a good PDF
rendering library would include security features which prevent
arbitrary file/network access from untrusted documents by default or at
least give you the ability to control that.
--Sean
More information about the security-dev
mailing list