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