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

[Bernd Eckenfels]

Just to add another point to this. Today it is quite hard to use operating system facilities like chroot/jails, security tokens, seteuid, dropping priveledges or switching Security tokens which would allow to limit or escalate priveledges in an OS enforced manor. If we would have a bit more support of that, some sandbox mechanisms might actually be able to replace a security manager and/or open new features like processing workload with actual user accounts, etc.

I am however not sure what mechanism would be needed (and possible given the complete runtime) for that and how to make it able to support multiple OS with that. Maybe it would be an os specific optional facility? Something like SAPs shared memory with multiple processes maybe as an option for easy spawning of contained worklads?


--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Peter Tribble <peter.tribble at gmail.com>
Gesendet: Thursday, May 13, 2021 9:25:25 AM
An: Ron Pressler <ron.pressler at oracle.com>
Cc: Alan Bateman <alan.bateman at oracle.com>; Peter Firmstone <peter.firmstone at zeus.net.au>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

> On 12 May 2021, at 22:41, Peter Tribble <peter.tribble at gmail.com<mailto: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/7fa8509a/attachment.htm>