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: Fri, 23 Jun 2006 16:22:12 +0200 Organization: LAAS-CNRS Message-ID: <87r71g7y0b.fsf@laas.fr> References: <20060612182036.2c989469@localhost.localdomain> <87ver6z5ga.fsf@laas.fr> <871wtuuj1v.fsf@ossau.uklinux.net> <873bdxtlml.fsf@laas.fr> <449AE346.3050306@mail.msen.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1151072594 12008 80.91.229.2 (23 Jun 2006 14:23:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Jun 2006 14:23:14 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Jun 23 16:23:08 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 1FtmYi-0005mu-Rb for guile-user@m.gmane.org; Fri, 23 Jun 2006 16:22:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FtmYi-00005t-AT for guile-user@m.gmane.org; Fri, 23 Jun 2006 10:22:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FtmYc-0008Uh-OU for guile-user@gnu.org; Fri, 23 Jun 2006 10:22:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FtmYa-0008TO-QH for guile-user@gnu.org; Fri, 23 Jun 2006 10:22:49 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FtmYa-0008TL-Mh for guile-user@gnu.org; Fri, 23 Jun 2006 10:22:48 -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 1Ftmjn-00074T-P0 for guile-user@gnu.org; Fri, 23 Jun 2006 10:34:24 -0400 Original-Received: by laas.laas.fr (8.13.7/8.13.4) with SMTP id k5NEMMSd029218; Fri, 23 Jun 2006 16:22:43 +0200 (CEST) Original-To: Alan Grover In-Reply-To: <449AE346.3050306@mail.msen.com> (Alan Grover's message of "Thu, 22 Jun 2006 14:36:54 -0400") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) X-URL: http://www.laas.fr/~lcourtes/ X-Revolutionary-Date: 5 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: Alan Grover , guile-user@gnu.org X-Spam-Score: 0 () X-Scanned-By: MIMEDefang at CNRS-LAAS 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:5386 Archived-At: Hi, Thanks for your comments and the nice links! Alan Grover writes: > One approach is to write your own security-manager/white-list. You scan > the s-expr, check the symbols in the head of any (sub-)list, and fail if > they aren't approved. I don't really like this approach, it looks quite "ugly" and impractical IMO, and it could only be made to work when one has access to the source code. Instead, evaluating untrusted code in an environment that only provides access to the necessary bindings and resources (as I suggested), thereby honoring the principle of least authority (POLA), really looks nicer. > I think there is a R5RS way of doing code-confinement. The R5RS spec > says that the null-environment "is empty except for the (syntactic) > bindings for all syntactic keywords defined in this report that are > either required or both optional and supported by the implementation." I > take it to mean that you are guaranteed the required keywords, might > have the optional keywords, but won't have anything else. Right. Then you still lack control over the resources used by the untrusted code. > Beware, you have to provide a comprehensive black-list. Imagine if the > guile 1.6 null-environment didn't include every optional-keyword, but > 1.8 did. Untrusted code could take advantage of the difference. You also > have to carefully consider the impact of allowing any keyword. For > example, "let" would allow the untrusted code to do an infinite loop > (via named-let). Good point: "black listing" is obviously more risky than "white listing" because you can always forget an important binding. > I can't find the place where I originally found this method, but there > is another example at > http://www.cap-lore.com/CapTheory/Language/Scheme/SchemeFactory.html > and the preceding pages. You may want to read these pages to understand > some other issues around untrusted code. This is a very nice reading. It also refers to Jonathan Reed's ``A Security Kernel Based on the Lambda-Calculus'' [0] which I'm going to read as soon as I can! :-) >> 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. > > You can also write a safe-interpreter in scheme, and thus in the same > process. You solve the above issues by charging the expression each time > it applies a procedure, each time it consumes heap (roughly at each > "cons"), etc. The changes I was describing are the minimal changes that look necessary to write such a "safe interpreter" (you don't need that if you run the untrusted code as a separate process: you can rely on `setrlimit' and friends). As for control over heap allocation: unfortunately, rebinding `cons' to a restricted version of `cons' (for instance, once that enforces some quota) would not be sufficient in Guile. This is because, for instance, memory for SMOBs, vectors, etc., is not allocated via `cons'. Controlling calls to `scm_cell ()' would be better, but still insufficient. And anyway, one could hardly control the heap used by SMOBs (because there's more than one way SMOBs can allocate memory)... (Of course, we are clearly not considering invocation of untrusted C code by the untrusted Scheme code!) > This one is for chicken: > http://www.call-with-current-continuation.org/eggs/sandbox.scm > And, again, I can't locate a reference to the original example of this, > I believe it was R5RS though. Hmm, I'm not sure I understand how it works. Thanks, Ludovic. [0] http://mumble.net/~jar/pubs/secureos/ _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user