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-r...@openjdk.java.net> im Auftrag von Peter Tribble <peter.trib...@gmail.com> Gesendet: Thursday, May 13, 2021 9:25:25 AM An: Ron Pressler <ron.press...@oracle.com> Cc: Alan Bateman <alan.bate...@oracle.com>; Peter Firmstone <peter.firmst...@zeus.net.au>; security-dev@openjdk.java.net <security-dev@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.press...@oracle.com<mailto:ron.press...@oracle.com>> wrote: > On 12 May 2021, at 22:41, Peter Tribble > <peter.trib...@gmail.com<mailto: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/
