guile-user
[Top][All Lists]
Advanced

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

Re: Secure evaluation


From: David Allouche
Subject: Re: Secure evaluation
Date: Mon, 14 Jul 2003 17:34:20 +0200
User-agent: Mutt/1.5.4i

On Mon, Jul 14, 2003 at 11:36:28AM +0200, Joris van der Hoeven wrote:
> 
> I would like to use Guile Scheme for scripts inside documents,
> a bit like Javascript in Html. Does there exist any mechanism which
> forbids the use of dangerous instructions like (system "rm -rf /")
> or maybe even instructions which may lead to infinite loops?

In case you do not get a more specific answer by more knowledgeable
people here:

I remember there was some discussion about EVAL in latter versions of
GUILE (see the compat.scm file in texmacs) taking an "environment"
parameter (which is how R5RS specifies EVAL).

I believe it is possible to create an empty environment in which only
the desired functions are imported; and there is a relationship
between modules and environments (modules can be used as
environments).

Probably you could try searching the archives for "module environment
eval" and maybe "sandbox" keywords.

A quick googling yielded this thread in the archive:
http://mail.gnu.org/archive/html/guile-user/2001-09/msg00055.html

In a nutshell, that seems to be possible with guile 1.6.

This other post from Marius Vollmer mentions a "safe-eval-string"
procedure which uses such a "safe" environment.
http://mail.gnu.org/archive/html/guile-user/2003-06/msg00036.html

This one mentions the "make-safe-module" procedure which is probably
used internally with safe-eval-string.
http://mail.gnu.org/archive/html/guile-user/2001-05/msg00193.html

Another related thread:
http://mail.gnu.org/archive/html/guile-user/2001-03/msg00081.html

It also seems there are special provisions to be made for glue
functions:
http://mail.gnu.org/archive/html/guile-user/2002-10/msg00078.html

I think the main problems you would have are:

 -- The cost of building the module for each evaluation. Maybe not
    such a big deal.

 -- Protecting the included modules from changes caused by SET! from
    the sandbox module.

The latter problem is the most difficult, because to get a useful safe
environment you are going to import a bunch of utility modules in it.
However, a malevolent (or buggy) script should not be allowed to break
havoc in other modules.

But maybe I am misunderstanding how SET! interacts with modules (I
have not tested) and maybe it is not possible to modify another module
by SET!ing an imported binding.

-- 
                                                            -- ddaa




reply via email to

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