[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?
Thanks,
Mark