[plt-scheme] (in)security in a top-level eval

At Tue, 20 Feb 2007 10:02:46 +0000, support at taxupdate.com wrote:
> I'm developing a program which includes eval's on user-generated code.  Before
> getting too far down this road, I'd like to be clear on the security issues.
> 
> Currently, I enclose user code within a security guard that should prevent file
> writes and network access.  But the code is eval'ed at the top level, so I'm
> wondering what type of concerns this brings up.  Any guidance?

In addition to the other things mentioned so far, you should change the
current code inspector. The most obvious effect is to cut off access to
unsafe FFI functions:

 > (current-code-inspector (make-inspector))
 > (require (lib "foreign.ss"))
 > (unsafe!)
 readline::72: compile: access from an uncertified context to protected
 variable from module: |,/Users/mflatt/proj/plt/collects/mzlib/foreign|
 in: unsafe!

It also prevents misuse via `expand' of internal functions that appear
in macro expansions.


Unfortunately, I see one problem that MzScheme doesn't currently
address: a program could keep open too many file descriptors. There's
currently no custodian-based limit on file descriptors, though I've
been meaning to add it for a while. Along with a limit on OS-level
subprocesses (which is not an issue if you prevent "execute" filesystem
access), I think that would cover a-priori limits on scarce resources.


Overall, then, you want:

 * a security guard to prevent disk and network access (be sure to
   disable all "execute" filesystem operations);

 * a code inspector to prevent access to privileged operations; and

 * a custodian for easy shutdown (in case the program runs too long),
   including custodian-based

     - memory limits to prevent excessive memory use, and

     - file-descriptor limits to prevent too many open files, etc.
       *** not available, yet, but hopefully soon! ***

Those are all the security issues that I can see, at least, for
sandboxing code in an embedded MzScheme.


Matthew