Re: Sandboxing Kawa

[Per Bothner <per@bothner.com>]

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/