JEP 411: sandboxing use case

[Sean Mullan]

On 1/10/22 9:22 AM, Olivier Cailloux wrote:
> Dear list,
> 
> I would like to share my use case for currently using the security
> manager mechanism (SM) in my software. Now that JEP 411 is there, any
> advice about any currently existing solution for replacement would be
> welcome, if this is already possible; alternatively, I hope that a
> replacement for these needs will be available soon.

You may want to consider container technologies. This is mentioned in 
the last paragraph of the Motivation section of JEP 411.

--Sean

> 
> My software grades student work. It download their code from GitHub,
> compiles it, runs it, and observe the results (similar to running JUnit
> tests, but on pluggable code). Their code is then graded automatically
> depending on the expected versus actual results.
> 
> I currently use SM to prevent student code to alter the system on which
> the code runs or have external impact. I don’t want them to read files
> or send network requests (they usually do not need to do anything like
> this for the exercices assigned to them). I currently use a simple “no
> priviledged calls at all” configuration, where everything that can be
> forbidden by SM is forbidden for their code, as they only need to be
> able to deal with their own objects and classes from the JDK that
> operate “taint-free” (as Chapman Flak puts it), such as classical List
> or Set structures.
> 
> Though I do not currently need such more advanced feature, I considered
> as a good bonus that SM allowed me, if I wanted to, to give exercices
> that also deal with file writing (through telling SM that their code
> can access a restricted set of files). If any replacement solution
> could also allow this kind of flexibility, that would be nice.
> 
> I am aware that their code could implement a denial of service; I am
> okay to live with this risk as any resulting damage would be low (worst
> case, just restart the computer). But I’d like to reduce the risk that
> their code would read or modify files or other aspects of the system it
> is running on, for example, as the resulting damage could be much
> higher (such as: alter the way the system works so that the grading of
> other students, graded next, would be modified; read personal files
> from the account that is running the grading software and posting their
> content on the internet; inadvertently delete files on the host
> system…)
> 
> I implement code isolation so that one student code does not see or
> interact with the code of other students classical using class loader
> mechanisms, for which JEP 411 does not create problems. But I ignore
> how to prevent file writing, socket opening, or similar stuff, using
> other means than SM.
> 
> My needs resemble (but are not identical to) the ones exposed by
> Chapman Flack in “JEP 411: Missing use-case: user functions in an
> RDBMS”, https://marc.info/?m=162216583127042. I share the concern of
> this poster (https://marc.info/?m=162221303911911) that it currently
> seems that I’d have to come up with various, specialized mechanisms to
> prevent various kinds of operations (file system access, socket
> access, …), which seems inelegant and error-prone.
> 
> Even after reading the insightful article of Ron Pressler, Shallow Java
> Sandboxes
> (https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/),
> it is unclear to me whether I can get rid of SecurityManager with
> existing Java 17 technology. Any advice would be welcome. If not
> possible, please consider this use case when thinking about further
> progress in replacing the security related APIs. (I am quite worried by
> the wording of JEP 411 Future Work not mentioning this kind of
> sandboxing need.)
> 
> Olivier
> 
>