How to safely expose Lisp webserver to arbitrary sexp input?
in [Lisp]
|
From: jkc on 4 Jun 2010 14:09 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
From: Pascal J. Bourguignon on 4 Jun 2010 14:18 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? If you are considering a chrooted environment, why not a virtual machine? You could use either Xen or user-mode-linux, and everytime you have to run alien code, you'd boot a new virtual machine. Well configured, it wouldn't be slower than anything else. You don't need to boot a whole OS, basically, just the kernel and the lisp implementation, as init process. Have a look at: http://www.informatimago.com/linux/emacs-on-user-mode-linux.html -- __Pascal Bourguignon__ http://www.informatimago.com/
From: Captain Obvious on 4 Jun 2010 16:58 j> There are a number of ways to do this, of course. My question is, how j> might one do this to minimize threats to security? I think doing it on Lisp side is hard. Basic idea (as I would do it) is to execute code in a sandbox environment which explicitly includes only safe functions/macros/special operators. E.g. you can create package SANDBOX and import there only symbols which are known to be safe. If there is a need to call inherently unsafe function, it can be made via a wrapper which checks arguments etc. Then you make sure code you've read only uses symbols in SANBOX and no symbols outside. If code can access only functions which have no effects on outside world, the only ways it can do harm are: * hang in infinite loop * blow away stack through recursion * blow away heap through excessive allocation It might be tricky to deal with those -- some things might be tolerated by underlying implementation, but I don't think it is reliable. Probably the safest way is to write your own interpreter which constantly monitors progress and aborts execution if something goes wrong. If performance is an issue, code instrumentation might be a solution -- all pieces which can be non-safe should be instrumented with checks. E.g. (sketch): (defmacro dotimes-sandbox ((i n) &body body) `(cl:dotimes (,i ,n) (do-sandbox-checks) ,@body))) (defun do-sandbox-checks () (incf *sandbox-iterations*) (when (> *sandox-iterations* +sandbox-max-iterations+) (error 'sandbox-error "max iterations reached"))) Also, I think it is obvious that reader needs to be secured. I think best way is to write your own security-concerned stripped-down reader. So maybe it is easier to do it via whole OS virtualization.
From: jkc on 4 Jun 2010 17:28 On Jun 4, 11:18 am, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > > If you are considering a chrooted environment, why not a virtual machine? > > You could use either Xen or user-mode-linux, and everytime you have to > run alien code, you'd boot a new virtual machine. Well configured, it > wouldn't be slower than anything else. > > You don't need to boot a whole OS, basically, just the kernel and the > lisp implementation, as init process. Have a look at:http://www.informatimago.com/linux/emacs-on-user-mode-linux.html > > -- > __Pascal Bourguignon__ http://www.informatimago.com/ What an interesting idea - I hadn't thought of doing it through a VM. I'll have to think about how to incorporate that within the context of an existing web framework. Jeff Cunningham
From: jkc on 4 Jun 2010 17:31
On Jun 4, 1:58 pm, "Captain Obvious" <udode...(a)users.sourceforge.net> wrote: > j> There are a number of ways to do this, of course. My question is, how > j> might one do this to minimize threats to security? > > I think doing it on Lisp side is hard. > Basic idea (as I would do it) is to execute code in a sandbox environment > which explicitly includes only safe functions/macros/special operators. > > E.g. you can create package SANDBOX and import there only symbols which are > known to be safe. > If there is a need to call inherently unsafe function, it can be made via a > wrapper which checks arguments etc. > > Then you make sure code you've read only uses symbols in SANBOX and no > symbols outside. > > If code can access only functions which have no effects on outside world, > the only ways it can do harm are: > * hang in infinite loop > * blow away stack through recursion > * blow away heap through excessive allocation > > It might be tricky to deal with those -- some things might be tolerated by > underlying implementation, but I don't think it is reliable. Probably the > safest way is to write your own interpreter which constantly monitors > progress and aborts execution if something goes wrong. If performance is an > issue, code instrumentation might be a solution -- all pieces which can be > non-safe should be instrumented with checks. > > E.g. (sketch): > > (defmacro dotimes-sandbox ((i n) &body body) > `(cl:dotimes (,i ,n) > (do-sandbox-checks) > ,@body))) > > (defun do-sandbox-checks () > (incf *sandbox-iterations*) > (when (> *sandox-iterations* +sandbox-max-iterations+) > (error 'sandbox-error "max iterations reached"))) > > Also, I think it is obvious that reader needs to be secured. I think best > way is to write your own security-concerned stripped-down reader. > > So maybe it is easier to do it via whole OS virtualization. I had hoped it might be possible without writing a different interpreter. In what way does the reader need to be secured? --Jeff Cunningham |