Restricting eval

Restricting eval

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

Hi,
I am still working on the implementation
of Chess in Scheme that I mentioned before.

For now, the most important part is to provide
a language to describe rules of board games.
Until recently, the descriptions were all
pattern-based, which was a rather natural
approach, but it turned out that it was limited
too, because it didn't allow me to specify
e.g. that neither a king nor a rook was allowed
to move before castling, or that the captured
pawn's move must have been made in a previous
turn in case of the en-passent capture.

So I decided provide an environment where
some arbitrary Scheme code (specified in the
ruleset) could be executed, and where certain
functions would reside that could be called
by that code.

And now I have a decision to make. One option
would be to create my own, restricted meta-circular
evaluator for a minimalistic subset of Scheme
(or use one that is already available). But I think
that it would be reinventing the wheel which is
already present in Guile Scheme, and is called
"eval" (or perhaps even "compile").

And hence my question: is there any way to restrict
the execution environment of eval, e.g. to specify
which symbols should be available? (For security
reasons, I wouldn't want functions like "system"
or "exit" to be present in that environment)

Or perhaps there's some better way to do that?

Regards,
M.

[-- Attachment #2: Type: text/html, Size: 1878 bytes --]

Re: Restricting eval

[Grant Rettke]

On Sat, Nov 30, 2013 at 2:26 PM, Panicz Maciej Godek
<godek.maciek@gmail.com> wrote:
> And hence my question: is there any way to restrict
> the execution environment of eval, e.g. to specify
> which symbols should be available? (For security
> reasons, I wouldn't want functions like "system"
> or "exit" to be present in that environment)
>
> Or perhaps there's some better way to do that?

How did you end up achieving your goal?

Re: Restricting eval

[Panicz Maciej Godek]

Hi!

2014-03-23 19:07 GMT+01:00 Grant Rettke <grettke@acm.org>:
> On Sat, Nov 30, 2013 at 2:26 PM, Panicz Maciej Godek
> <godek.maciek@gmail.com> wrote:
>> And hence my question: is there any way to restrict
>> the execution environment of eval, e.g. to specify
>> which symbols should be available? (For security
>> reasons, I wouldn't want functions like "system"
>> or "exit" to be present in that environment)
>>
>> Or perhaps there's some better way to do that?
>
> How did you end up achieving your goal?

Oh, with Guile it turned out to be a piece of cake ;]
It's thanks to first-class modules and the fact that a module can be
provided as the second argument to eval.
Guile actually has e.g. (ice-9 safe-r5rs), which exports a safe subset
of Scheme, and (ice-9 null), which provides the most basic syntactic
bindings and no functions whatsoever.

So it is possible to either create a module in runtime using
make-fresh-user-module and add all the necessary bindings, or to have
some regular module prepared and obtain it using resolve-module.

This is more or less how I did it, but I have to admit that I did
neglect the security issues and designed the system to work rather
than to make it hacker-proof.

The bad news is that the module API isn't officially documented and
one needs to read the boot-9.scm file to figure out how it works (the
code is a good read, though).

HTH

Re: Restricting eval

[Grant Rettke]

Understood. Thanks for sharing that.

On Sun, Mar 23, 2014 at 1:33 PM, Panicz Maciej Godek
<godek.maciek@gmail.com> wrote:
> Hi!
>
> 2014-03-23 19:07 GMT+01:00 Grant Rettke <grettke@acm.org>:
>> On Sat, Nov 30, 2013 at 2:26 PM, Panicz Maciej Godek
>> <godek.maciek@gmail.com> wrote:
>>> And hence my question: is there any way to restrict
>>> the execution environment of eval, e.g. to specify
>>> which symbols should be available? (For security
>>> reasons, I wouldn't want functions like "system"
>>> or "exit" to be present in that environment)
>>>
>>> Or perhaps there's some better way to do that?
>>
>> How did you end up achieving your goal?
>
> Oh, with Guile it turned out to be a piece of cake ;]
> It's thanks to first-class modules and the fact that a module can be
> provided as the second argument to eval.
> Guile actually has e.g. (ice-9 safe-r5rs), which exports a safe subset
> of Scheme, and (ice-9 null), which provides the most basic syntactic
> bindings and no functions whatsoever.
>
> So it is possible to either create a module in runtime using
> make-fresh-user-module and add all the necessary bindings, or to have
> some regular module prepared and obtain it using resolve-module.
>
> This is more or less how I did it, but I have to admit that I did
> neglect the security issues and designed the system to work rather
> than to make it hacker-proof.
>
> The bad news is that the module API isn't officially documented and
> one needs to read the boot-9.scm file to figure out how it works (the
> code is a good read, though).
>
> HTH



-- 
Grant Rettke | ACM, AMA, COG, IEEE
grettke@acm.org | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Re: Restricting eval

[Mark H Weaver]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> 2014-03-23 19:07 GMT+01:00 Grant Rettke <grettke@acm.org>:
>> On Sat, Nov 30, 2013 at 2:26 PM, Panicz Maciej Godek
>> <godek.maciek@gmail.com> wrote:
>>> And hence my question: is there any way to restrict
>>> the execution environment of eval, e.g. to specify
>>> which symbols should be available? (For security
>>> reasons, I wouldn't want functions like "system"
>>> or "exit" to be present in that environment)
>>>
>>> Or perhaps there's some better way to do that?
>>
>> How did you end up achieving your goal?
>
> Oh, with Guile it turned out to be a piece of cake ;]
> It's thanks to first-class modules and the fact that a module can be
> provided as the second argument to eval.
> Guile actually has e.g. (ice-9 safe-r5rs), which exports a safe subset
> of Scheme, and (ice-9 null), which provides the most basic syntactic
> bindings and no functions whatsoever.
>
> So it is possible to either create a module in runtime using
> make-fresh-user-module and add all the necessary bindings, or to have
> some regular module prepared and obtain it using resolve-module.

It turns out that it's trivial to access any binding from any module,
even from code evaluated in a module with a restricted set of bindings.

  http://lists.gnu.org/archive/html/guile-devel/2012-05/msg00041.html

I regret calling it a "Psyntax security hole", since Guile has never
claimed to support secure sandboxing, but it's something to keep in
mind.

I'd like to add support for secure sandboxing in a future version of
Guile, but in the meantime you'd better run it in a VM or container if
that's what you want.

     Mark