[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Psyntax security hole prevents secure sandboxing in Guile

From: Mark H Weaver
Subject: Re: Psyntax security hole prevents secure sandboxing in Guile
Date: Mon, 07 May 2012 13:44:49 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

address@hidden (Ludovic Courtès) writes:
> Mark H Weaver <address@hidden> skribis:
>> Every once in a while someone asks about secure sandboxing with Guile,
>> and generally the response is that it should be fairly easy, by creating
>> a module with carefully selected bindings, but there's nothing ready
>> "out of the box".
>> I just realized that psyntax has a security hole that prevents secure
>> sandboxing, and wanted to post this fact before it was forgotten.
> There are many other holes, such as the fact that ‘@@’ is compiled to
> the ‘toplevel-ref’ instruction, which can search inside modules.

'@@' can be rebound, so that its default binding is no longer available:

   scheme@(guile-user)> (@@ (ice-9 popen) open-pipe*)
   $1 = #<procedure open-pipe* (mode command . args)>
   scheme@(guile-user)> (define @@ 2)
   scheme@(guile-user)> (@@ (ice-9 popen) open-pipe*)
   ;;; <stdin>:3:4: warning: possibly unbound variable `ice-9'
   ;;; <stdin>:3:4: warning: possibly unbound variable `popen'
   ;;; <stdin>:3:0: warning: possibly unbound variable `open-pipe*'
   <unnamed port>:3:4: In procedure #<procedure 103199b0 at <current input>:3:0 
   <unnamed port>:3:4: In procedure module-lookup: Unbound variable: ice-9
   Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
   scheme@(guile-user) [1]> 

In the past, some of us (including me) have suspected that by creating a
module with all dangerous bindings removed (including '@' and '@@'), one
could create a secure sandbox in Guile.  Sadly, that is not the case.

>> The problem is that psyntax accepts syntax-objects in the input, and
>> syntax-objects are simply vectors (or sexps containing vectors).
> I agree it would be nice to fix eventually, using structs, but it takes
> more than this to allow for “secure sandboxing”.

Can you think of anything else that would need to be fixed, besides this
problem with forgeable syntax-objects?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]