From: Günther Thomsen on
On Jun 4, 2:31 pm, jkc <jeffrey.k.cunning...(a)gmail.com> wrote:
> In what way does the reader need to be secured?
>
reader-macros seem to be dangerous in this context, particularly #.
From: Günther Thomsen on
On Jun 4, 11:09 am, jkc <jeffrey.k.cunning...(a)gmail.com> wrote:
> Suppose one wanted to set up a Lisp-based website such that visitors
> could submit Lisp code to run within a test framework. The code
> submissions might be by file upload where the file contained at least
> one function with a pre-defined interface.
>
> There are a number of ways to do this, of course. My question is, how
> might one do this to minimize threats to security?
>
What kinds of security threads do you have in mind? If, e.g. the user
shall not be able to upload code, which, when executed on the server
connects to a third party and does nasty things there, then running
the server in a VM by itself wont suffice. At least a packet filter
which assures that the server doesn't initiate outgoing (TCP)
connections is required.

I'm afraid, this is a fairly hard problem to get right and near
futile, if that server is to be exposed to the Internet.
From: Tim X on
jkc <jeffrey.k.cunningham(a)gmail.com> writes:

> Suppose one wanted to set up a Lisp-based website such that visitors
> could submit Lisp code to run within a test framework. The code
> submissions might be by file upload where the file contained at least
> one function with a pre-defined interface.
>
> There are a number of ways to do this, of course. My question is, how
> might one do this to minimize threats to security?
>
> I figured I would need to run the webserver out of user-space, and
> possibly in a chrooted environment. But what Lisp-specific issues
> might arise? Is there any way to do this safely?
>
> Regards,
> Jeff Cunningham

This is actually a tricky problem to get right. In fact, you will only
be able to reduce the threat and not eliminate it. I'm assuming the code
to be evaluated is not meant to affect how the web server and framework
operate i.e. is evaluated in its own context.

I would ensure that the code to be evaluated is 'sandboxed' as much as
possible and that it is a separate user space to your web server and its
code. One possible approach would be to setup a framework where you pass
the submitted code via a network connection to a sandboxed (possibly running
on a virtual host) lisp process for evaluation and have the result
returned via the network socket.

The 'sandboxed' lisp interpreter would be locked down by having
'dangerous' (however you define those) functions
removed/blocked/modified etc. Identifying these will be difficult. The
VM could be further locked down by having VM level firewalls,
restricted/removed 'dangerous' programs, etc. Essentially, you will need
a modified 'tainted' lisp environment. Not sure if it would be easier to
try and lock down an existing one or implement your own interpreter.
Much depends on what range of features/functionality you want to
provide. Obviously, the more powerful an environment you provide the
more likely it will be insecure.

You will also need to set things up so that every submitted bit of code
(or code submitted from the same user) is evaluated in its own
environment, separate from others. You would probably also want to do an
initial 'scan' of the code submitted to identify some of the nastier
constructs.

Finally, you would need some sort of circuit breaker to recover from
systems that appear to be in an infinite loop. You will also have issues
with resource hogging and allocation i.e. stopping code submitted by
user A from impacting on what is submitted by user B etc.

You might find the bioBike system interesting. It is built on lispWorks
and provides a web based programming environment (although it is a
specialised DSL rather than a general lisp). Possibly some good ides to
'borrow'.

See http://www.biolisp.org/

Tim


--
tcross (at) rapttech dot com dot au
From: Barry Margolin on
In article
<330a82a5-9477-4ffd-a8b1-b0f846222b91(a)11g2000prw.googlegroups.com>,
jkc <jeffrey.k.cunningham(a)gmail.com> wrote:

> Suppose one wanted to set up a Lisp-based website such that visitors
> could submit Lisp code to run within a test framework. The code
> submissions might be by file upload where the file contained at least
> one function with a pre-defined interface.
>
> There are a number of ways to do this, of course. My question is, how
> might one do this to minimize threats to security?
>
> I figured I would need to run the webserver out of user-space, and
> possibly in a chrooted environment. But what Lisp-specific issues
> might arise? Is there any way to do this safely?

One thing you have to do is ensure that they can't redefine the
functions that implement the server itself. Some implementations allow
you to "lock" a package, and will signal an error if any of the
functions in the package are redefined outside the source file that
originally defined them.

A harder problem may be to prevent them from assigning to important
global variables used by the implementation.

--
Barry Margolin, barmar(a)alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: jkc on
On Jun 4, 8:37 pm, Tim X <t...(a)nospam.dev.null> wrote:
te it. I'm assuming the code
> to be evaluated is not meant to affect how the web server and framework
> operate i.e. is evaluated in its own context.
>
> I would ensure that the code to be evaluated is 'sandboxed' as much as
> possible and that it is a separate user space to your web server and its
> code. One possible approach would be to setup a framework where you pass
> the submitted code via a network connection to a sandboxed (possibly running
> on a virtual host) lisp process for evaluation and have the result
> returned via the network socket.
>

Interesting comments. What about an approach which instantiates a VM
instance of an interpreter for each code submission with _no_
networking interface? It just starts up, reads the code it is to run
from a text file it finds in its sandbox, runs it, writes its output
file and dies - whether it wants to or not. Sort of like the
replicants in Bladerunner. The VM environment would be set up so it
had very limited capabilities.

--Jeff Cunningham