<div dir="ltr"><div><div dir="ltr">On Wed, May 12, 2021 at 10:49 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> On 12 May 2021, at 22:41, Peter Tribble <<a href="mailto:peter.tribble@gmail.com" target="_blank">peter.tribble@gmail.com</a>> wrote:<br>
> <br>
> Let me give a concrete example:<br>
> <br>
> Parsing and rendering a PDF file that may contain references to fonts or other resources.<br>
> We know exactly where the files are installed, so wish to allow the rendering routine access<br>
> to the fonts it will need. But not to any other files, and not (normally) to network resources at<br>
> all. Note that we trust the code, but not necessarily the document it's parsing. (Although the<br>
> document itself may be perfectly well formed - document formats often allow embedding<br>
> references to 3rd-party objects, undesirable as that may be.)<br>
> <br>
<br>
Thank you. Let me ask you this, then:<br>
<br>
1. Would allowing access to certain files and no network for the *entire* application be<br>
sufficient? Consider that you can run some code in a separate Java process with OS protections.<br>
If not, why not?<br></blockquote><div><br></div><div>Unfortunately not. We're already running this in a separate sandboxed Java process to provide a<br>basic level of isolation. But that process has to interact with the outside world - it has to get the<br>file in the first place, and put the result somewhere (which may be to a filesystem or to a networked<br>system such as S3). Generally, the permitted level of access will vary depending on where we are<br></div><div>in the rendering process.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. Would turning such access on and off for the entire application through some Java process<br>
be sufficient?<br></blockquote><div><br></div><div>That's effectively what we're doing right now. Essentially we do:<br><br></div><div>doRender() {<br></div><div>  installSecurityManager();<br></div><div>  do3rdPartyRender();<br></div><div>  uninstallSecurityManager();<br>}<br><br></div><div>which is fine because we are in a dedicated sandbox and can be sure that we aren't doing anything else<br>at the time.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
3. Would controlling such access on a per-thread basis be sufficient?<br></blockquote><div><br></div><div>In a way, that would be more flexible, as we wouldn't need the stop-the-world blanket restriction.<br></div><div>It does, however, rely on the assumption that once you've applied the restriction to a thread then<br></div><div>the do3rdPartyRender() and anything it calls is also restricted to that thread.<br><br></div><div>In our specific use case, because we have separate processes already, we would probably aim for 2<br>rather than 3. But I can certainly see why 3 is attractive in general - it allows you to tie a restriction to<br>a given execution context.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Please don’t read 2 or 3 as some concrete proposals; I’m just trying to understand the requirements.<br>
<br>
— Ron<br>
<br>
</blockquote></div><br></div>Thanks,<br clear="all"><div><br>-- <br><div dir="ltr" class="gmail_signature">-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a></div></div></div>