http://qs321.pair.com?node_id=55350

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

I have in the past and am considering in the future using the Safe module to provide semi-public access to a local Perl interpreter. I'm familiar with all of the options and opcode groups, and can configure it to be what appears to be completely safe as far as executing untrusted code goes. My questions are these:
  1. The Safe documentation makes it plain and clear that using the module is no guarantee of security/safety in executing untrusted code. Barring any undiscovered bugs/exploits, however, is it for all practical purposes reasonably safe to use it in this fashion? Is there some fundamental flaw in its implementation or are there any known ways of circumventing its protection? I realize there's always the possibility of some hole allowing unauthorized access to certain Perl opcodes, but I'm trying to identify the level of risk involved here.
  2. Is there an easy/common way of addressing the DoS aspect of running untrusted code? With Safe, I can prohibit them from executing stuff I don't want them to execute, but I can't keep them from writing a tight while (1) {} loop and tying up the CPU, or making it so the code never returns. My first thought is to use setpriority to reduce adverse affects, and alarm to catch any code running an inordinate amount of time, but is this safe? What if the evil code modifies $SIG{ALRM}?
I realize this is a risky thing to do, and additional security precautions I'm considering involve chroot and others. Can anyone think of any other caveats?

Replies are listed 'Best First'.
Re: Known security issues with Safe.pm?
by AgentM (Curate) on Jan 31, 2001 at 00:49 UTC
    You might try a simple server architecture, which depending on your needs, may be truly-threaded or simply forked. Runaway processes can be easily STOPped or KILLed if your server is paying attention. Invoking a forked process prepended with the "nice" command is certainly an option. Using SIGALRM is generally a bad idea for any security considerations. You could also give the "modified" interpreter a separate user or group in which you can set limits of quota, swap usage, CPU time and system time. That's sounds like alot of encapsulation for an untrusted user who would have access to your system. Is it really worth it? Under the best circumstances, you'd probably need a separate computer to guarantee the safety of your own stuff. The unltimate answer depends on how much you can trust your users or how much you are able to track them (Which libs should they not have access to, etc.) If you need more help, or if you want Olga to call, just reply below...
    AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.
[reply]
      Exactly. I'm just trying to get a full feel for my options here and weigh that against the risk I'm willing to assume. Forking off a new process seems like another good alternative as far as compartmentalizing the code, leaving the parent running and able to watch over it.
[reply]
Re (tilly) 1: Known security issues with Safe.pm?
by tilly (Archbishop) on Jan 31, 2001 at 08:22 UTC
    May I suggest solving this problem with User Mode Linux? This allows you to create a very tightly controlled environment which you can duplicate exactly very easily with (AFAIK) no way out of the controlled compartment. On the outside you can easily block attempts at network traffic, limit CPU usage, protect yourself from using too much memory, disk space, etc. But from the inside it looks like a normal machine..

    BTW there are a number of gotchas with Safe. I have found that interesting code (eg stuff that uses Exporter) tends not to play well with Safe...

[reply]
      Wow, this UML thing is damn cool. This will be my new toy for the next week or two. Forget about this other project. It's going in the background.
[reply]

Back to Seekers of Perl Wisdom