[Top][All Lists]
[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
- Secure evaluation, Joris van der Hoeven, 2003/07/14
- Re: Secure evaluation,
David Allouche <=