From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludovic.courtes@laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.user Subject: Re: modify environments to make sandboxes Date: Thu, 22 Jun 2006 14:34:10 +0200 Organization: LAAS-CNRS Message-ID: <873bdxtlml.fsf@laas.fr> References: <20060612182036.2c989469@localhost.localdomain> <87ver6z5ga.fsf@laas.fr> <871wtuuj1v.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1150979730 2972 80.91.229.2 (22 Jun 2006 12:35:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Jun 2006 12:35:30 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Jun 22 14:35:27 2006 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FtOP8-0005kQ-Dg for guile-user@m.gmane.org; Thu, 22 Jun 2006 14:35:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FtOP7-00064C-H3 for guile-user@m.gmane.org; Thu, 22 Jun 2006 08:35:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FtOOY-0005j0-KP for guile-user@gnu.org; Thu, 22 Jun 2006 08:34:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FtOOV-0005hZ-Jn for guile-user@gnu.org; Thu, 22 Jun 2006 08:34:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FtOOV-0005hT-8Q for guile-user@gnu.org; Thu, 22 Jun 2006 08:34:47 -0400 Original-Received: from [140.93.0.15] (helo=laas.laas.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FtOZT-0007jA-B5 for guile-user@gnu.org; Thu, 22 Jun 2006 08:46:07 -0400 Original-Received: by laas.laas.fr (8.13.7/8.13.4) with SMTP id k5MCYbWb010484; Thu, 22 Jun 2006 14:34:39 +0200 (CEST) Original-To: Neil Jerram X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 4 Messidor an 214 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEB1F5364 X-PGP-Key: http://www.laas.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: powerpc-unknown-linux-gnu Mail-Followup-To: Neil Jerram , Mildred , guile-user@gnu.org In-Reply-To: <871wtuuj1v.fsf@ossau.uklinux.net> (Neil Jerram's message of "Mon, 12 Jun 2006 23:05:00 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS X-MIME-Autoconverted: from 8bit to quoted-printable by laas.laas.fr id k5MCYbWb010484 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:5382 Archived-At: Hi, Neil Jerram writes: > ludovic.courtes@laas.fr (Ludovic Court=E8s) writes: > >> Code confinement is indeed an interesting feature. Fortunately, Guile >> offers various ways to do it (AFAIK, there's no standard way to do thi= s >> in R5RS Scheme). :-) [...] > > That's a very nice explanation. Is there a good place for it > somewhere in the manual? (If not, perhaps we should start a "How can > I do XXX" section.) (Sorry, I think I had skipped this message.) We don't have "how to" sections in the manual, but for this specific topic, perhaps we could add a subsection under "The Guile module system"? Note that control over a module's name space (as described in my post) is not the only thing needed to safely evaluate untrusted code. The user would also need finer control over all the resources used by the code at hand (in order to prevent DoS attacks), particularly memory (heap and stack) and CPU. Unfortunately, I don't think this can be realized using Guile, except maybe by running the untrusted code in a separate process and relying on the OS' resource accounting mechanisms (e.g., `setrlimit' --- but Guile core doesn't provide bindings for it). However, running untrusted code in a separate process would preclude, practically, resource sharing with the user's trusted code (e.g., an Xchat Scheme plug-in would be useless as a separate process because it would be unable to access the data structures of the "real" Xchat). The "ideal" solution would imply things like: * changing the evaluator so that several evaluators with different `eval-options' can be instantiated (pretty much like the `guile-reader' approach); this way, untrusted code could be evaluated with an evaluator that has custom stack limits; * having, roughly, a `current-heap' fluid that would be referred to anytime heap is allocated (hmm...); * similarly, have CPU time slice capabilities that would be passed to `eval' either explicitly or via a fluid. But, well, going back to the documentation issue at hand, perhaps we can just mention that Guile lacks certain features to allow for really safe execution of untrusted code. ;-) Thanks, Ludovic. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user