On Wed, May 12, 2021 at 10:49 PM Ron Pressler <ron.press...@oracle.com>
wrote:
>
> > On 12 May 2021, at 22:41, Peter Tribble <peter.trib...@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/
