Sandboxing Kawa

Sandboxing Kawa

[Mark Raynsford]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

Hello.

I'd like to embed Kawa into a Java program, using it as a base for a
custom Scheme-like (but almost certainly not R*RS compatible) language.
Leaving aside resource handling issues (such as scripts exhausting all
available memory, spinning at 100% cpu usage, etc), I'm trying to work
out how I can expose an utterly spartan bare-minimum interpreter to the
host program that can only call a few functions that I expose to it.
Anyone familiar with embedding Lua into a C program (or even into a
Java program via something like Rembulan [0]) will probably be
familiar with the idea: The language is used just to provide the basic
syntax and evaluation semantics, but the standard library is more or
less completely removed and replaced with a bare minimum API relevant
to the domain in question. Doing this provides a relatively safe
sandbox, because the sandboxed code simply doesn't have access to any
functions that can do anything dangerous.

I'd like to state beforehand that I'm trying to avoid using the Java
SecurityManager unless it's utterly unavoidable (due to performance and
administrative concerns, along with the fact that Oracle might be
deprecating it eventually).

I have the following questions after playing with the Kawa API a bit:

1. Is it possible to restrict the initially available symbols in a
kawa.standard.Scheme instance to a tiny core subset (such as lambda,
if, define, begin, etc)? A default Scheme instance in Kawa has 807
symbols in the environment.

2. Is it possible to restrict the interpreter to only working with a
single java.nio.file.FileSystem? I'd like it if any attempt to do I/O
went through a given filesystem instance. I don't mind if I have to
implement my own I/O library to do this.

3. Is it possible to restrict the classes that the interpreter is
allowed to access or import? For example, right now nothing stops the
someone from writing (java.lang.System:exit 0).

[0] https://github.com/mjanicek/rembulan

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Sandboxing Kawa

[Per Bothner]

On 11/22/2017 12:10 PM, Mark Raynsford wrote:
> I have the following questions after playing with the Kawa API a bit:
> 
> 1. Is it possible to restrict the initially available symbols in a
> kawa.standard.Scheme instance to a tiny core subset (such as lambda,
> if, define, begin, etc)? A default Scheme instance in Kawa has 807
> symbols in the environment.

The default Kawa environment is defined by the (two) calls to
loadClass("kawa.lib.kawa.base", xxx) in kawa/standard/Scheme.java.
So all of the initially visible names are defined by kawa.lib.kawa.base
(defined in kawa/lib/kawa/base.scm).  So you can replace kawa.lib.kawa.base
to a "smaller" initial library.

I suggested creating sub-classes of kawa.standard,Scheme and
kawa.standard.SchemeCompilation.

In addition you need to override checkDefaultBinding from
SchemeCompilation.  The easiest and most reliable is just have it return null.

> 2. Is it possible to restrict the interpreter to only working with a
> single java.nio.file.FileSystem? I'd like it if any attempt to do I/O
> went through a given filesystem instance. I don't mind if I have to
> implement my own I/O library to do this.
> 
> 3. Is it possible to restrict the classes that the interpreter is
> allowed to access or import? For example, right now nothing stops the
> someone from writing (java.lang.System:exit 0).

Both of these require disabling "backdoors" to Java classes, methods,
fields.  Overriding ,checkDefaultBidning and maybe the colon
operator should do that.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Sandboxing Kawa

[Mark Raynsford]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

On 2017-11-22T20:57:31 +0100
Per Bothner <per@bothner.com> wrote:

> On 11/22/2017 12:10 PM, Mark Raynsford wrote:
> > I have the following questions after playing with the Kawa API a bit:
> > 
> > 1. Is it possible to restrict the initially available symbols in a
> > kawa.standard.Scheme instance to a tiny core subset (such as lambda,
> > if, define, begin, etc)? A default Scheme instance in Kawa has 807
> > symbols in the environment.  
> 
> The default Kawa environment is defined by the (two) calls to
> loadClass("kawa.lib.kawa.base", xxx) in kawa/standard/Scheme.java.
> So all of the initially visible names are defined by kawa.lib.kawa.base
> (defined in kawa/lib/kawa/base.scm).  So you can replace kawa.lib.kawa.base
> to a "smaller" initial library.
> 
> I suggested creating sub-classes of kawa.standard,Scheme and
> kawa.standard.SchemeCompilation.
> 
> In addition you need to override checkDefaultBinding from
> SchemeCompilation.  The easiest and most reliable is just have it return null.

Right.

> > 2. Is it possible to restrict the interpreter to only working with a
> > single java.nio.file.FileSystem? I'd like it if any attempt to do I/O
> > went through a given filesystem instance. I don't mind if I have to
> > implement my own I/O library to do this.
> > 
> > 3. Is it possible to restrict the classes that the interpreter is
> > allowed to access or import? For example, right now nothing stops the
> > someone from writing (java.lang.System:exit 0).  
> 
> Both of these require disabling "backdoors" to Java classes, methods,
> fields.  Overriding ,checkDefaultBidning and maybe the colon
> operator should do that.

OK, thanks! I'll try those as a first pass implementation.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]