This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Sandboxing Kawa
- From: Per Bothner <per at bothner dot com>
- To: Mark Raynsford <list+org dot sourceware dot kawa at io7m dot com>, kawa at sourceware dot org
- Date: Wed, 22 Nov 2017 20:57:31 +0100
- Subject: Re: Sandboxing Kawa
- Authentication-results: sourceware.org; auth=none
- References: <20171122111055.21383f32@copperhead.int.arc7.info>
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/