From: Nyang A. Phra
Subject: Sandboxing CL?
Date: 
Message-ID: <37174d58-b84c-47f0-8161-4d223f41bc39@v67g2000hse.googlegroups.com>
Is there any nice and easy way to create a subset language of CL, so
that expressions not belonging to that subset language are not
evaluated?

My problem is this: I generate more or less random strings that are
fed to the CL interpreter; I'd like to make sure nothing undesired
happens, as the contents of the generated strings are not restricted
(they could theoretically be syntactically invalid LISP or system
calls that execute "rm -rf /", or whatever).

IOW, I'd like to create a safe sandboxed language and test arbitrary
programs written in that language. Is there any neat way to "outlaw"
some expressions (mostly I/O and system call, and like) in CL, or do I
need to look for other approaches? I could always restrict the
contents of the generated strings, but that'd be suboptimal in my case.

From: Pascal Costanza
Subject: Re: Sandboxing CL?
Date: 
Message-ID: <60jdlrF1r4vbvU1@mid.individual.net>
Nyang A. Phra wrote:
> Is there any nice and easy way to create a subset language of CL, so
> that expressions not belonging to that subset language are not
> evaluated?
> 
> My problem is this: I generate more or less random strings that are
> fed to the CL interpreter; I'd like to make sure nothing undesired
> happens, as the contents of the generated strings are not restricted
> (they could theoretically be syntactically invalid LISP or system
> calls that execute "rm -rf /", or whatever).
> 
> IOW, I'd like to create a safe sandboxed language and test arbitrary
> programs written in that language. Is there any neat way to "outlaw"
> some expressions (mostly I/O and system call, and like) in CL, or do I
> need to look for other approaches? I could always restrict the
> contents of the generated strings, but that'd be suboptimal in my case.

The straightforward way is to define your own package, and only import 
the subset of the common-lisp package that you want to support (or wrap 
the common-lisp definitions with your own definitions that can specify 
further restrictions).

However, this doesn't provide the level of security you seem to be 
looking for: Your random strings could contain accesses to "cl:..." or 
even "cl::..." definitions (or also accesses to potentially internal 
symbols in other packages). Common Lisp doesn't provide a way to make 
things more secure here. The only way around this I can think of is to 
define your own parser from strings to s-expressions that can filter out 
the things you don't want. I am not aware about libraries which could 
you here, although they probably exist...

Pascal

-- 
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/

My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Sohail Somani
Subject: Re: Sandboxing CL?
Date: 
Message-ID: <kx0pj.6542$w57.2975@edtnps90>
On Sat, 02 Feb 2008 04:51:50 -0800, Nyang A. Phra wrote:

> IOW, I'd like to create a safe sandboxed language and test arbitrary
> programs written in that language. Is there any neat way to "outlaw"
> some expressions (mostly I/O and system call, and like) in CL, or do I
> need to look for other approaches? I could always restrict the contents
> of the generated strings, but that'd be suboptimal in my case.

The easiest way is to use OS facilities. There is some way to monitor a 
program and kill it if it calls some specific system calls. I forget what 
it is now...

http://www.xs4all.nl/~weegen/eelis/geordi/#faq might get you started.

-- 
Sohail Somani
http://uint32t.blogspot.com
From: Thomas A. Russ
Subject: Re: Sandboxing CL?
Date: 
Message-ID: <ymi63x435em.fsf@blackcat.isi.edu>
"Nyang A. Phra" <······@gmail.com> writes:

> Is there any nice and easy way to create a subset language of CL, so
> that expressions not belonging to that subset language are not
> evaluated?

You build your own interpreter.

Given that this is Lisp, it's not actually that hard to do, and there
are several examples around.

-- 
Thomas A. Russ,  USC/Information Sciences Institute