How to safely expose Lisp webserver to arbitrary sexp input?
in [Lisp]
|
From: jkc on 5 Jun 2010 10:27 On Jun 5, 3:04 am, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > Tim X <t...(a)nospam.dev.null> writes: > > 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. This approach looks promising - UML in particular, as at first glance it looks like it would be easier to set up and might be faster to launch. I'm assuming it could be launched with a timeout similar to the way you sketch in Xen above? --Jeff Cunningham
From: Pascal J. Bourguignon on 5 Jun 2010 10:42 jkc <jeffrey.k.cunningham(a)gmail.com> writes: > On Jun 5, 3:04�am, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: >> Tim X <t...(a)nospam.dev.null> writes: > >> > 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. > > This approach looks promising - UML in particular, as at first glance > it looks like it would be easier to set up and might be faster to > launch. I'm assuming it could be launched with a timeout similar to > the way you sketch in Xen above? Definitely. -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Tim X on 5 Jun 2010 20:36 pjb(a)informatimago.com (Pascal J. Bourguignon) writes: > 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. Your right, that is easy and obvious. However, the hard part is knowing what sort of timeout to set. This is what I was referring to when I referenced the halting problem. Still, even that is in reality minor compared to ensuring the security of the system, which IMO is the real issue and getting that balance right is what will be difficult. Tim -- tcross (at) rapttech dot com dot au
From: D Herring on 6 Jun 2010 00:03
On 06/05/2010 08:36 PM, Tim X wrote: > pjb(a)informatimago.com (Pascal J. Bourguignon) writes: >> Or said otherwise, you don't need to solve the halting problem, only >> the halting before the timeout problem which is trivial to solve. > > Your right, that is easy and obvious. However, the hard part is knowing > what sort of timeout to set. This is what I was referring to when I > referenced the halting problem. Still, even that is in reality minor > compared to ensuring the security of the system, which IMO is the real > issue and getting that balance right is what will be difficult. Think GC. Reasons to halt a visitor's VM: - user disconnects (could allow a reconnect?) - server low on resources (e.g. cpu, memory, disk) - VM started attacking others The first two are relatively easy. The last may be easy if you block all network access except to the user. Later, Daniel |