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

[Peter Tribble]

On Wed, May 12, 2021 at 10:49 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
> > On 12 May 2021, at 22:41, Peter Tribble <peter.tribble at gmail.com> 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.)
> >
>
> Thank you. Let me ask you this, then:
>
> 1. Would allowing access to certain files and no network for the *entire*
> application be
> sufficient? Consider that you can run some code in a separate Java process
> with OS protections.
> If not, why not?
>

Unfortunately not. We're already running this in a separate sandboxed Java
process to provide a
basic level of isolation. But that process has to interact with the outside
world - it has to get the
file in the first place, and put the result somewhere (which may be to a
filesystem or to a networked
system such as S3). Generally, the permitted level of access will vary
depending on where we are
in the rendering process.


> 2. Would turning such access on and off for the entire application through
> some Java process
> be sufficient?
>

That's effectively what we're doing right now. Essentially we do:

doRender() {
  installSecurityManager();
  do3rdPartyRender();
  uninstallSecurityManager();
}

which is fine because we are in a dedicated sandbox and can be sure that we
aren't doing anything else
at the time.


> 3. Would controlling such access on a per-thread basis be sufficient?
>

In a way, that would be more flexible, as we wouldn't need the
stop-the-world blanket restriction.
It does, however, rely on the assumption that once you've applied the
restriction to a thread then
the do3rdPartyRender() and anything it calls is also restricted to that
thread.

In our specific use case, because we have separate processes already, we
would probably aim for 2
rather than 3. But I can certainly see why 3 is attractive in general - it
allows you to tie a restriction to
a given execution context.


> Please don’t read 2 or 3 as some concrete proposals; I’m just trying to
> understand the requirements.
>
> — Ron
>
>
Thanks,

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210513/c8a684fd/attachment.htm>