guile-user
[Top][All Lists]
Advanced

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

[guile-user] Sandboxing?


From: Bobby D. Bryant
Subject: [guile-user] Sandboxing?
Date: Mon, 12 Mar 2001 20:22:48 +0600

I have started using GUILE for user-customizable configuration files for
compiled programs.  There were several reasons for choosing GUILE, and
one of the most obvious is that it allows you to specify code as well as
passive data in a configuration file.  For instance, I am working on a
game program that will allow user customizations, and a customizer may
want to express the cost of an action or a thing in the game as a
function rather than as a simple number.

However, this immediately brings up the possibility of pranksters
putting dangerous code in configuration files.

I don't worry about this too much for entire applications (whether
written in GUILE or any other language), because I ass-u-me that most
people are fairly careful about getting their applications from a known
source, and that if the application is semi-popular there will be a lot
of people looking at the code.

However, I also ass-u-me that people will not in general be quite so
careful about where they get game customization files.  While a game
program might have a standard source, customization files tend to pop up
everywhere, and thus will be subject to less control and less pre-use
scrutiny than the program itself is.  Moreover, Joe Gamer probably won't
even realize that a customization file can bear executable code, and
probably wouldn't recognize dangerous Scheme code even if he did decide
to read the files.

So what's an application programmer to do?

 o Refuse to execute code in configuration files? -- Too restrictive.

 o Analyze user-specified code for safety at run time? -- Not
computationally feasible.

 o Use a dumb safety filter, e.g. do a simple search of user-specified
code and reject it if it includes known-to-be-dangerous functions such
as (system ...).  -- Feasible, but it still leaves some questions...

Is it possible to make a comprehensize list of "dangerous" built-in
functions?  Is it feasible to always detect user-specified aliases for
dangerous built-ins?  Or there other things a safety filter should look
for, or things that a dumb filter could never catch?

I realize that there's probably no protection against things such as a
recursive procedure that builds up a list until memory is exhausted and
the application crashes, but I would at least like to protect against
the most obvious dangers, such as modifying or deleting files in your
directory tree, changing your password, sending out e-mail in your name,
etc.

Also, if some sort of sandboxing does prove to be feasible and
desirable, should it be done at the application level, or could it be
done in GUILE itself so that it does not have to be done in every
application that uses it?  (I'm not suggesting a blanket hamstringing of
GUILE, but rather a switch that an application could optionally invoke.
Maybe the C =enter= function could take an argument that
enabled/disabled some degree of sandboxing.)

Any general thoughts on the topic, or specific safety recommendations,
will be appreciated.

Bobby Bryant
Austin, Texas





reply via email to

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