Prev: Simple hack to get $500 to your home.
Next: line-move-visual
From: jkc on 5 Jun 2010 00:08
On Jun 4, 8:38 pm, Barry Margolin <bar...(a)alum.mit.edu> wrote:

>
> 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.
>

If they are running a solo instance which isn't part of the web server
environment, it shouldn't matter if they take it over or hose it up -
so long as it commits suicide after a short period of time. Or is
murdered by the launching host. Seems like the key would be to
seriously restrict its ability to do anything but read and write
text.

--Jeff Cunningham
From: Tim X on 5 Jun 2010 02:44
jkc <jeffrey.k.cunningham(a)gmail.com> writes:

> 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.
>

The main issue I'd see here is the "and dies - whether it wants to or
not" - not sure how you would garantee this and know when/how to force
it to when that is necessary. Essentially, its the halting problem. .
The VM would need to run as some sort of asynchronous process so that it
doesn't block.

Getting the right balance between something which is powerful enough to
be of interest but at the same time not dangerous is the hard part.

Tim

--
tcross (at) rapttech dot com dot au
From: Captain Obvious on 5 Jun 2010 03:23
j> In what way does the reader need to be secured?

It is described in Let over Lambda book:

http://letoverlambda.com/index.cl/guest/chap4.html#sec_6
From: Pascal J. Bourguignon on 5 Jun 2010 05:46
G�nther Thomsen <guenthert(a)gmail.com> writes:

> 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.

My point would be that it's easier, and more secure, to configure a VM
with restricted network connectivity than to try to do it at the level
of the lisp implementation or of the the VM kernel (which is what you
try to do with a chroot environment, with the added security concerns
that the chroot kernel and the host kernel are the same, and there are
known ways to get out of the chroot jails).

With a VM, it's also easy to limit processor, memory (RAM and disk)
and time resources.

--
__Pascal Bourguignon__ http://www.informatimago.com/
From: Pascal J. Bourguignon on 5 Jun 2010 06:04
Tim X <timx(a)nospam.dev.null> writes:

> jkc <jeffrey.k.cunningham(a)gmail.com> writes:
>
>> 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.
>>
>
> The main issue I'd see here is the "and dies - whether it wants to or
> not" - not sure how you would garantee this and know when/how to force
> it to when that is necessary. Essentially, its the halting problem. .
> The VM would need to run as some sort of asynchronous process so that it
> doesn't block.
>
> Getting the right balance between something which is powerful enough to
> be of interest but at the same time not dangerous is the hard part.

This is easy, eg. with Xen (similarly with user-mode-linux, qemu, etc):

store_request_in_virtual_disk $disk
xm create $vm -c | read_result_from_the_console_with_timeout $allocated_time
xm destroy $vm

If you configure the lisp implementation as the init process, IIRC
when init exits, unix kernels finish.


Or said otherwise, you don't need to solve the halting problem, only
the halting before the timeout problem which is trivial to solve.


--
__Pascal Bourguignon__ http://www.informatimago.com/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Simple hack to get $500 to your home.
Next: line-move-visual