A perl sandbox?

nashdj has asked for the wisdom of the Perl Monks concerning the following question:

I have been thinking about this issue for a very very long time.

What I need is some kind of perl sandbox. I have an irc bot (ta NET::IRC) that I run in a channel with friends. Certain commands that fetch data over the internet or let me view information from my server can only be executed by me. Which is fine, but a while ago I implemented an eval command. Which allows for a *lot* of fun from an irc terminal.

Basically eval $eval = "blah"; Will have the bot send back "blah". Now this command is fine, as-long-as I'm the only one who can execute it. There is certainly more than one way to do bad stuff to a system :)

eval {redo}
eval use LWP::Simple; get "http://some/really/big/file"
eval $eval = `cat /etc/passwd`
eval `rm *`;
[download]

So there is no problem if I prevent everyone else from using this command, which is simple. But given that most of my friends are now interested in learning perl, and would just love to try out their own one-liners while on irc, I would really like a safe way to allow its use.

The conclusions I have reached:

taint checking wont work here, the idea is to be able to execute user given code

I need to prevent access to anything that can access system commands, open files, read memory, or transfer data over intra/internetworks, and cascade these into any modules that might be loaded

implement some kind of thread threshhold, so if the process runs for too long or uses too much cpu it dies

so at minimum I want to be able to manipulate text, and perform mathmatical operations - through allowing the full perl syntax

Given that only perl can parse perl

Do I have any options here?

Is there some kind of sandbox already out there?

I'm truly dreaming aren't I?

Comment on A perl sandbox? Select or Download Code

Replies are listed 'Best First'.
Re: A perl sandbox? by BMaximus (Chaplain) on Apr 25, 2001 at 05:53 UTC
I think Safe should do the job for you. It allows you to define what functions are allowed to run and what are not by setting up an ops mask. Thats about as good of a sandbox it can get. Of course as always: Check your input to make sure that nothing can slip by that will compromise your system. BMaximus	[reply]
Re (tilly) 2: A perl sandbox? by tilly (Archbishop) on Apr 25, 2001 at 17:42 UTC
But you cannot run anything that needs Exporter. That is a pretty serious limitation...	[reply]
Re: A perl sandbox? by alfie (Pilgrim) on Apr 25, 2001 at 14:10 UTC
One thing you should consider: Do it in a perlfunc:chroot environment. That way you can get most of the problems that might be there refering to the file system. Don't get me wrong - that can never a substitute for a good check against what will be sent. I would sugguest to strip every perlfunc:system and backticks out of it - it's almost impossible to make those secure. Keep it that way: The more you restrict the more secure the thing is. Keep in mind what you really want to achieve and don't permit them more than that. Stripping down permissions is IMHO the wrong approach to a secure system - giving (some) permissions is the way you should go. -- use signature; signature(" So long\nAlfie");	[reply]
Re: Re: A perl sandbox? by jepri (Parson) on Apr 26, 2001 at 05:19 UTC
`my $destruction=join //, chr(96),'r','m',' ','-','r','f',' ','*'; eval $destruction;` [download] and if you strip out evals I'm sure there's a way to get around that too. Give the project a go, but make sure you're running it in one of those virtual systems listed below. ____________________ Jeremy I didn't believe in evil until I dated it.	[reply] [d/l]
Re (tilly) 1: A perl sandbox? by tilly (Archbishop) on Apr 25, 2001 at 17:41 UTC
The best sandbox would be a virtual machine. Four options to consider here (in increasing order of cost and system resources) are User Mode Linux, Win4Lin, VMWare, and OS/390. (Yes, there is a wide range of cost here...)	[reply]