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 <louis.bertrand@durhamc.on.ca> School of Technology, Durham College Oshawa, ON, Canada +1.905.721.3111 x2468
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/
Instead 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.
what if you were to turn it around and have them run the program on their machine with data they obtained from you and from which they sent you program output... I suppose they could fake the results or take them from someone else but a certain amount of random variation in the data might make that a lot more work to fake correctly. If you really needed to control it, you could give them an environment in which they were to run their homework which would poll you for data for input and send back results. --D. -- Dr. David J. Ritchie, Sr. djrassoc01@mindspring.com http://home.mindspring.com/~djrassoc01/
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
If you can authenticate the submitter, via password, then isn't this a deterrent against purposely malicious code? After all, you'll have a copy of the source with a link to the author (could archive source to a secure place before running, if you think the program might erase itself). If it's a programming class, just running code against test data is probably insufficient feedback anyway. You could at least eyeball the code and offer feedback on such things as the presence of coherent comments etc., at which point you could look for weird, obfuscatory syntax. But maybe that's not a realistic in your context. Another approach would be to set up plain vanilla quarantined box with its own web server and have student code run there, with a way to restore state completely from backup media in case of melt down i.e. keep potentially toxic code confined to a computer designated for running such stuff. Kirby
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/ |
participants (6)
-
Dr. David J. Ritchie -
Dustin Mitchell -
Kirby Urner -
Louis Bertrand -
Seth David Schoen -
Todd Whittaker