On Wed, Apr 24, 2002 at 06:52:14PM -0400, Louis Bertrand wrote:

Hello,

I'm exploring the idea of having my students submit their programming assignments through a Web dropboxand having those assignments automatically marked by a script that runs the submitted program with pre-arranged test data, catching any boo-boos with exceptions.

Here's the problem: this plan violates the secure programming principle that you should never treat data as code and I might be leaving myself open for some serious malware.

Does anyone have any experience with restricting the privileges of a running Python program?

Yes, but don't trust any of them. Any such restriction is like trying to stop a river .. it's going to get through eventually. I would suggest that you look into, e.g., rexec[1], but construct your web dropbox such that *you* review the code before executing it. That is, students drop it in and it's timestamped. Then you come along whenever, enter some password, and are presented with a list of ungraded submissions. You call one up, look over the code, and decide to press or not press the "run" button. Rexec will catch anything straightforward, and likely anything tricky enough to get around rexec will stick out like a sore thumb in your reading of the code. Dustin [1] http://www.python.org/doc/current/lib/module-rexec.html -- Dustin Mitchell dustin@ywlcs.org http://people.cs.uchicago.edu/~dustin/

Louis, I have implemented such a system, and the insecurity of it still gives me the shivers. But, I can assert that it surely makes grading laboratory exercises **much** easier. Permit me to make a few suggestions: 1. Have students authenticate to your system. This will prevent the general cracker audience from dropping in just any old program. They'd at least need to compromise a username/password pair first. 2. Don't trust any input that the user actually gives, such as a username or lab number. Look up their input in a database of permitted labs, and then you can use your own data to construct paths for where to place the uploaded files. 3. It's good to run it chrooted. However, even this isn't enough unless you're clever enough to put each individual submission into its own jail, otherwise students can still write scripts to read each other's files. A better suggestion would be to set up a jail that can run a Java virtual machine with a security policy file. Then, use Jython to compile the Python scripts into Java .class files, and execute those. It's been my long term goal to rewrite what I have working, and provide it as GPL'd software, but that's a large number of weekend hacking sessions away. Good luck! -- Todd ------------------------------------------------------------- Todd A. Whittaker mailto:todd@thewhittakers.org http://www.thewhittakers.org/~todd/ ------------------------------------------------------------- On Wed, 24 Apr 2002, Louis Bertrand wrote:

Hello,

I'm exploring the idea of having my students submit their programming assignments through a Web dropboxand having those assignments automatically marked by a script that runs the submitted program with pre-arranged test data, catching any boo-boos with exceptions.

Here's the problem: this plan violates the secure programming principle that you should never treat data as code and I might be leaving myself open for some serious malware.

Does anyone have any experience with restricting the privileges of a running Python program?

As a first pass, I would: * run Python in a chroot(2) jail * load the jail with only the bare minimum to run Python and remove networking and os modules (at least). * scan the submitted programs for usage of sys.path.

Any other suggestions?

Thanks --Louis

Louis Bertrand writes:

Hello,

I'm exploring the idea of having my students submit their programming assignments through a Web dropboxand having those assignments automatically marked by a script that runs the submitted program with pre-arranged test data, catching any boo-boos with exceptions.

Here's the problem: this plan violates the secure programming principle that you should never treat data as code and I might be leaving myself open for some serious malware.

Does anyone have any experience with restricting the privileges of a running Python program?

As a first pass, I would: * run Python in a chroot(2) jail * load the jail with only the bare minimum to run Python and remove networking and os modules (at least). * scan the submitted programs for usage of sys.path.

"Scanning the submitted programs" for anything is always tougher than it sounds. Just looking at that one example, it's easy to disguise a reference to sys.path: import sys as fun forbidden = fun.path or alternatively, a much more complicated approach, import sys, md5 forbidden = eval("sys."+filter(lambda x:md5.md5(x).hexdigest()=='d6fe1d0be6347b8ef2427fa629c04485',dir(sys))[0]) or a way to avoid mentioning the "sys" part: import sys i = "" for i in globals().values(): try: i.getrecursionlimit fooled_you = i.path break except: pass -- Seth David Schoen <schoen@loyalty.org> | Reading is a right, not a feature! http://www.loyalty.org/~schoen/ | -- Kathryn Myronuk http://vitanuova.loyalty.org/ |