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

[Mark Raynsford]

On 2021-05-06T11:46:33 +0000
Ron Pressler <ron.pressler at oracle.com> wrote:
> When the entire process has the same permissions — in line with current practice — there are 
> superior sandboxes provided by the OS.

The issue with falling back to the sandboxes provided by the OS is that
you then have to deal with a lot of platform-specific code in order to
actually configure that sandbox. On some platforms, the application
might have to run initially with a _higher_ level of privilege just in
order to be able to switch to a lower level of privilege
(consider setuid(), for example). Given that the JVM is conceptually
supposed to be about not having to worry too much about what platform
you're deploying on, having to do platform-specific work like this is
always a bit unwelcome.

It would be nice if there was a portable API where I could say
something like "make me a new JVM with a subset of these modules, and
with OS-specific limits and access control configured so that the child
VM has this set of provided capabilities". The Chrome browser has
rather a lot of code to handle this, including setting up seccomp
policies on Linux platforms, (I believe) Capsicum policies on FreeBSD,
and all kinds of things elsewhere.

I may just be dreaming, but it'd be great if the successor to the
security manager could give us a portable, system-independent API that
could give us the desired sandbox setup on each underlying platform. :)

-- 
Mark Raynsford | https://www.io7m.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20210506/a48dd787/attachment.sig>