Run-time configurable sandboxes

org.openjdk at io7m.com org.openjdk at io7m.com
Mon May 25 15:41:48 UTC 2015


Hello!

I am a security-conscious Java developer and am interested in using the
JVMs built-in security features to run code in separated and run-time
configured sandboxes. I'm writing to the list to explain some of the
issues I've come up against and am hoping to either elicit suggestions
or at least provoke some discussion about how the JVM might better
support this.

I've been working on a small experimental system for sandboxing
due to dissatisfaction with the existing sandboxing packages.
The existing sandboxing packages appear to be overly complicated,
fragile, and unmaintained. They almost all implement a complicated
and error-prone custom security manager and seem to more or less
ignore everything else the JVM has in terms of security features.
I'm hoping that I can do better!

My own use case will be running code that is sandbox-aware and that
only uses a few classes from java.lang and talks to an API that I
provide to each sandbox. I would expect to restrict arbitrary file
I/O (with sandboxed code persisting state via provided key/value
interface), restrict network I/O, restrict access to native code,
restrict access to reflection, restrict thread creation, and restrict
exiting the VM. About the only thing I cannot protect against is
heap exhaustion (but the JVM does a decent job of enforcing a global
limit anyway, so it's not as if malicious code would end up killing
the user's machine or running afoul of operating system limits).

It seems that others have somewhat similar use cases, often using
some sort of sandbox to provide security to embedded languages that
have been compiled to JVM bytecode at run-time.

I won't bore anyone here with the details of how the JVM applies
security policy because I'd assume everyone on this list already
understands it.

My basic approach has been to use a custom implementation of
java.security.Policy[0] and a custom classloader. The program
creates one classloader C per application sandbox S and assigns
all classes loaded by C a protection domain P. My assumption is
that for a particular sandbox, we no longer care about fine-grained
per-CodeSource control of classes inside the sandbox as we're more
likely to be applying a coarse sandbox-wide set of restrictions. This
then means that that the custom Policy implementation can assign
permissions on a per-sandbox basis by simply checking the CodeSource
URL and returning any permissions defined for that URL.

As a concrete example, I create a sandbox that I then assign
a URL of http://sandbox.io7m.com/1. The classloader for that
sandbox assigns every loaded class a CodeSource with location
http://sandbox.io7m.com/1. Now, whenever the AccessController consults
the policy's checkPermission function, the policy simply uses the
set of permissions defined for http://sandbox.io7m.com/1.

As an aside, I do use a custom SecurityManager but only to add a couple
of extra checks for Thread and ThreadGroup creation/modification,
because the default SecurityManager is not strict enough.

This appears to work well. I've been unable to subvert the sandbox and
am reasonably confident in its security simply due to the fact that it
does absolutely nothing clever whatsoever and uses the basic provided
JVM security features to achieve it. The code is less than 150 lines
and is not exciting in any way. The bulk of a real implementation
would be providing a pleasant API and a nice way to configure policies
at run-time.

My main gripes:

1. The ClassLoader and SecureClassLoader classes are not very nice. It
seems that I cannot take an existing classloader and preserve all
of the semantics with regards to mapping names to byte arrays (such
as looking through the classpath for class files, contacting remote
servers for classes, etc) if I want to maintain my own control over
the resulting ProtectionDomains of those classes. It is likely that
ProtectionDomains and CodeSources were never intended to be used in
the slightly abusive way I'm using them in the above system. I'm
guessing also that the implementations carry a ton of historical
baggage and would likely not have their interfaces presented in the
way they currently are if they were written/designed today!

There is a tempting package-private method in java.lang.Class called
setProtectionDomain that I'm not allowed to call. Having access to this
would allow me use any existing class loader and simply overwrite the
protection domains of the resulting classes without having to modify
any code.

2. I feel like I should not have to do any of the things I have done!
I realize this sounds silly, but if it were possible to label classes
with a simple immutable opaque tag indicating their confinement, and
the Policy could refer to this tag... I'd already be done. I would
assume that setting a confinement label on a class would require
security checks and that it could only be set once. This seems
almost too good/simple an approach to be true - would it require
an unlimited amount of bureaucracy to get something like this into
the standard library? It obviously exists to support a specific use
case, but I could see how the same approach could be used to provide
a generalized sandbox for anything compiled to JVM bytecode running
inside a scripting engine, for example.

I'm open to flames and/or suggestions on better approaches.

Mark

--

[0] Not essential for sandboxing, but essential for run-time
configuration, because the default Policy is obviously loaded from a
file on JVM startup, can't be easily/pleasantly updated, and likely
references a policy file that contains system-specific defaults that
I'd like to ignore!




More information about the security-dev mailing list