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

The top-level shouldn't cause you any problems. Just create a new
namespace for the eval'd code and it will only be able to use that
namespace.

You will probably want to make a separate thread (and eventspace if in
mred) in case the code runs forever. To protect against code that
attempts to allocate all of the memory in your program, use
custodian-limit-memory.

If you want to run more than one program, or make sure that the the
program  doesn't open too many files (or create too many threads) use
a custodian to clean up after it.

All of these things are being used in drscheme to protect it against
buggy/malicious code being evaluated at the REPL. You can read more
about that here: http://www.ccs.neu.edu/scheme/pubs/icfp99-ffkf.pdf

Note that that paper was written at a time before we had the GC
technology to do custodian-limit-memory. Now we do, but it requires
you to use the 3m collector. That collector is the default in the
nightly & SVN builds, but not in the latest official release.

hth,
Robby

On 2/20/07, support at taxupdate.com <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?
>
> Wayne
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>