From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.lisp.guile.user Subject: Re: Embedding Guile with sandboxing Date: Sat, 21 Nov 2015 22:39:06 +0100 Organization: Informatimago Message-ID: <87vb8vvxqd.fsf@kuiper.lan.informatimago.com> References: <1E9F5137-A070-4E3B-A781-FBAE80810FE6@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1448141997 1579 80.91.229.3 (21 Nov 2015 21:39:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2015 21:39:57 +0000 (UTC) To: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Nov 21 22:39:47 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a0Fso-0006tI-Q3 for guile-user@m.gmane.org; Sat, 21 Nov 2015 22:39:46 +0100 Original-Received: from localhost ([::1]:53763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0Fso-0002fX-IB for guile-user@m.gmane.org; Sat, 21 Nov 2015 16:39:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0Fsf-0002fH-Nu for guile-user@gnu.org; Sat, 21 Nov 2015 16:39:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0Fsc-0005pW-Gx for guile-user@gnu.org; Sat, 21 Nov 2015 16:39:37 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:45417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0Fsc-0005oc-9v for guile-user@gnu.org; Sat, 21 Nov 2015 16:39:34 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1a0FsU-0006Dl-GS for guile-user@gnu.org; Sat, 21 Nov 2015 22:39:26 +0100 Original-Received: from amontsouris-654-1-265-21.w82-123.abo.wanadoo.fr ([82.123.148.21]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Nov 2015 22:39:26 +0100 Original-Received: from pjb by amontsouris-654-1-265-21.w82-123.abo.wanadoo.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Nov 2015 22:39:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 61 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: amontsouris-654-1-265-21.w82-123.abo.wanadoo.fr Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:NjY0YzdlMWIxOTA2ZWYwNzU5NTgxZDE4OTViZjJlNDY2NDVjMDMyNw== X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12171 Archived-At: Matthew Keeter writes: > I’m currently embedding Python in a C / C++ application that evaluates user-provided scripts. > > Obviously, this is terribly unsafe: user-provided scripts can execute arbitrary malicious actions, > and there’s no good way to sandbox Python in a desktop context. > > If I were to replace Python with Guile, is there a way to sandbox it so that arbitrary (perhaps > malicious) user-provided scripts can be run safely? Well, I would use ecl (Embeddable Common Lisp) rather, but the problem is not specific to a language. To ensure "safety", you need to _control_ things. Using a general algorithmic programming language with OS or platform interfaces will never be safe. What you need is to write your own implementation. It doesn't matter of what language. For example, you could take pypy, expurge it from the "dangerous" operations and go on with the resulting restricted python. Or you could do the same with guile or Common Lisp. The advantage of the later languages, is that it is easier to write languages in them, reusing parts of the existing infrastructure. I imagine the same can be done with pypy. On the other hand, if you mix metalinguistic layers, you may introduce leaking bugs. Ultimately, the problem comes down to the fact that the underlying hardware and OS layer is not safe itself. One easy way to allow potentially hostile code to run, is to make it run in a chroot, nope, we know it's not safe, so in its own virtual machine (either on an hypervisor or a qemu or simular), but, nope, we know it's not safe (there are exploitable bugs in hypervisors and qemu, etc). So you need to implement a language that won't provide any unwanted OS/platform API and that won't provide any way to generate code accessing to any unwanted feature, and that still allows user to write useful programs, while making no mistake; and since it will run on an unsafe platform, how will you ensure that a program written in your language will never be able to have any nefarious side effects? For example, the x86 MMU is turing complete. How do you ensure that there is no way any program written in your language will not have the side effect of introducing a nefarious program in the underlying MMU? Perhaps it would be easier to select good users, and just give them full Common Lisp with ecl (or full guile). -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk