Solving the shared-server security problem for Python

Question

So my group is trying to set up a shared-server environment for various and sundry web services. I think we've settled on setting disable_functions and disable_classes site wide in php.ini and php_admin_value to force open_basedir in each app's httpd.conf for php scripts, and passenger's user switching for ruby scripts.

We still need to find something for python though. Passenger does support python, but not for per-application security for specific sub-directories (it's all or nothing at the domain level).

Any suggestions?

(And if any of the previous doesn't make sense - well, I'm the guy who's supposed to set up the python support, not the guy who set up the php or ruby support, so there's still some "and then some magic happens" steps in there from my perspective).

Answer 1

Can you use chroot for the Python scripts to limit them to their respective directories?

Answer 2

Not clear if you know all the users personally, trust them to have relatively good intentions, or it's a public server that will be scanned, brute forced, ... You could look at sandbox exmaples from app engine, utility Mill, codePad and IronPython/ silverlight

http://utilitymill.com/

http://code.google.com/appengine/docs/python/

http://codepad.org/

http://ironpython-urls.blogspot.com/2008/06/try-python-python-in-browser-with.html

(also Brett Cannon's work

http://sayspy.blogspot.com/2007/05/i-have-finished-securing-python.html

Answer 3

Well, there is a system called virtualenv which allows you to run Python in a sort of safe environment, and configure/load/shutdown these environments on the fly. I don't know much about it, but you should take a serious look into it; here is the description from its web page (just Google it and you'll find it):

The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.4/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.

Or more generally, what if you want to install an application and leave it be? If an application works, any change in its libraries or the versions of those libraries can break the application.

Also, what if you can't install packages into the global site-packages directory? For instance, on a shared host.

In all these cases, virtualenv can help you. It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't use the globally installed libraries either).