Is there a “safe” subset of Python for use as an e

问题:

In the many Python applications I've created, I often create simple modules containing nothing but constants to be used as config files. Additionally, because the config file is actually a Python code file, I can add simple logic for changing variables depending on a debug level, etc.

While this works great for internal applications, I'd be wary about releasing such applications into the wild for fear of someone either accidentally, or maliciously, adding destructive code to the file. The same would hold true for using Python as an embedded scripting language.

Is there a subset of Python that is deemed "safe" for embedding? I realize how safe it can be considered is fairly subjective. However, Java Applets and Flash both have their security sandbox well defined. I'm wondering if there's a version of Python that has similar rules?

EDIT: I'm asking not so much because of the config file approach, but because I'm interested in implementing some scripting/plugin mechanisms into a newer app and don't want a plugin or script to be able to, say, delete files. That goes beyond the scope of what the application should be able to do.

回答1:

Here are a couple of links to give you an idea on what you're up against:

• How can I run an untrusted Python script safely (i.e. Sandbox)
• Capabilities for Python? by Guido himself

There is also a dead google code project at http://code.google.com/p/sandbox-python/

回答2:

No there is no production ready subset of Python that is "safe". Python has had a few sand box modules which were deprecated due to deficiencies.

Your best bet is to either create your own parser, or isolate the python process with syscall hooks and a jailed account.

Some people might point you to PyPy, but it is slow and unfinished.

回答3:

The PyMite VM fits the bill if all you need to do is set simple variables, loops, conditionals and functions. PyMite is tiny, written in C, uses a static memory pool and can be embedded. It has an extremely limited set of builtin functions that is easy to configure. Similarly, the only standard libraries are partial implementations of string, dict, list and sys. The PyMite VM is part of the python-on-a-chip project, so it was designed to run on microcontrollers, but can run on posix-style desktop systems. The downside is that PyMite is not as extensively de-bugged as other Python implementations.

回答4:

The pypy project offers sandboxing features, see http://doc.pypy.org/en/latest/sandbox.html .

回答5:

tinypy (tinypy.org) was made to be a small, embed-able Python subset written in the style of Lua. And as lua has a manner to create a sandbox, I estimate that tinypy could be hacked along the same vein. Since tinypy's code base is so small, it's pretty easy to learn and figure out how to change things around to fit your needs.

回答6:

AFAIK, some attempts were made in standard python library, but they were not successful. See Restricted Execution for details.

Warning

In Python 2.3 these modules have been disabled due to various known and not readily fixable security holes. The modules are still documented here to help in reading old code that uses the rexec and Bastion modules.

回答7:

I'd be wary about releasing such applications into the wild for fear of someone either accidentally, or maliciously, adding destructive code to the file.

Your native code that's "in the wild" is equally vulnerable to this attack; that it is in machine code is just a speed bump, and no security.

If you are extremely paranoid and want a higher speedbump, you could make your native app that hosts the script instance check a hash of the content. Then accidential changes are impossible; only deliberate changes would go to the trouble of updating the checksum. You could go further and check they were signed with a public key too; then only hacking your native app could let new scripts in.

But the sandboxing? Don't worry about it!

回答8:

You might try IronPython on Silverlight/Moonlight, as these guys impressively seem to be doing. There is a lot of great information on these types of IronPython applications from the Resolver One developers here.

回答9:

I don't really know much about exactly what security capabilities you get within the Java Virtual Machine or .NET runtimes, but you might want to consider if running your python code with Jython or IronPython might allow you to get added security.

回答10:

It's a little hard to understand what you're trying to do -- not enough details.

Are you hosting the native app and allowing the users to write plugins? Consider using an OS-level solution by running the Python application as a separate runtime process inside a jail/chroot/similar, and communicating over sockets.

Are you expecting your customers to host the native app and let "untrusted parties" write plugins? Is there a reason the solution above won't work? (E.g., the customer would like to deploy on weird OSs without such options...)

Are you expecting the same people to host the native app and the "untrusted script" and want to protect them from themselves? In the sense of protecting them from writing "os.remove" and having it do what they wrote? Can you explain why?

Note that sandboxing alone is often not enough without stricter constraints (maximum CPU cycles, maximum memory, memory ownership issues...)? What kind of maliciousness do you want to stop? Note that here, too, OSs have wonderful capabilities (priorities, killing processes, ulimits) that not all sandboxing environments replicate -- and are certainly less security-tested than the things in OSs. (I'd trust Linux not to have breakable ulimits before I'd trust PyPy not to enable a malicious coder to take up unbounded amounts of memory, simply because Linux has been attacked in the wild more.)

回答11:

For some discussion on issues previously met with the rexec module:

• http://mail.python.org/pipermail/python-dev/2002-December/031160.html
• http://mail.python.org/pipermail/python-dev/2003-January/031848.html

These came from Restricted Execution HOWTO.

回答12:

This sounds like what you want: Reviving Python restricted mode.

The Python interpreter has a built-in "restricted" mode, enabled by changing the __builtins__ magic variable. The article Paving the Way to Securing the Python Interpreter explains the trick in more detail. Note that to work completely, it needs a patch to the Python intrepreter; I do not know if it has already been applied.

For a pure python proof-of-concept, see his previous post A Challenge To Break Python Security.