Differences between revisions 25 and 26
Revision 25 as of 2011-11-07 21:56:55
Size: 8227
Editor: PaulBoddie
Comment: Fixed internal link.
Revision 26 as of 2012-11-22 00:16:58
Size: 8615
Editor: d207-6-251-22
Comment: wiki restore 2013-01-23
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Line 3: Line 4:
See also: [[Asking for Help/How can I run an untrusted Python script safely (i.e. Sandbox)|How can I run an untrusted Python script safely (i.e. Sandbox)]] (from the [[Asking for Help]] page), [[Security]].
See also: [[Asking for Help/How can I run an untrusted Python script safely (i.e. Sandbox)|How can I run an untrusted Python script safely (i.e. Sandbox)]] (from the [[Asking for Help|Asking for Help]] page), [[Security|Security]].
Line 7: Line 10:
Line 9: Line 13:
  * You could turn a wiki into an RAD development platform. You just draw up your interface with Wiki:WikiSyntax, write up a little bit of Python code, and bam- instant application. :)
    * This is somewhat similar to [[http://www.tiddlywiki.com/|TiddlyWiki]] - a !JavaScript-based Wiki which behaves like a Web-based sandboxed application - although that approach utilises the !JavaScript sandbox functionality in the Web browser, rather than accessing a sandboxed server-side application.
  * You could make a distributed code system, where not just resources, but functionality as well, can distribute safely over multiple computers.

* You could turn a wiki into an RAD development platform. You just draw up your interface with Wiki:WikiSyntax, write up a little bit of Python code, and bam- instant application. :)
  * This is somewhat similar to [[http://www.tiddlywiki.com/|TiddlyWiki]] - a JavaScript-based Wiki which behaves like a Web-based sandboxed application - although that approach utilises the JavaScript sandbox functionality in the Web browser, rather than accessing a sandboxed server-side application.

* You could make a distributed code system, where not just resources, but functionality as well, can distribute safely over multiple computers.
Line 15: Line 22:
A "Sandboxed Python" would let you permit or forbid modules, limit execution slices, permit or deny network traffic, constrain filesystem access to a particular directory (floated as "/"), and so on. It is also referred to as [[http://docs.python.org/lib/restricted.html|RestrictedExecution]], a topic brought up by Mitch Kapor at PyCon and noted on his [[http://blogs.osafoundation.org/mitch/000559.html#000559|blog]].
Line 17: Line 23:
Related topics include capabilities as mentioned in [[PythonThreeDotOh]], specifically [[http://mail.python.org/pipermail/python-dev/2003-March/034149.html|this message on "capability-mediated modules"]]. Some work has been done to support capabilities in languages with similar heritage to Python, notably [[http://caperl.links.org/|CaPerl]]. A "Sandboxed Python" would let you permit or forbid modules, limit execution slices, permit or deny network traffic, constrain filesystem access to a particular directory (floated as "/"), and so on. It is also referred to as [[http://docs.python.org/lib/restricted.html|RestrictedExecution]], a topic brought up by Mitch Kapor at [[PyCon|PyCon]] and noted on his [[http://blogs.osafoundation.org/mitch/000559.html#000559|blog]].


Related topics include capabilities as mentioned in [[PythonThreeDotOh|
PythonThreeDotOh]], specifically [[http://mail.python.org/pipermail/python-dev/2003-March/034149.html|this message on "capability-mediated modules"]]. Some work has been done to support capabilities in languages with similar heritage to Python, notably [[http://caperl.links.org/|CaPerl]].
Line 21: Line 31:
Line 22: Line 33:
Line 25: Line 37:
The Java and CLR/.NET runtimes support restricted execution, and these can be utilised through the Jython and IronPython variants of Python (as well as by other languages, obviously).
[[PyPy|PyPy]] has support for creating a sandboxed Python interpreter.
The Java and CLR/.NET runtimes support restricted execution, and these can be utilised through the Jython and [[IronPython|IronPython]] variants of Python (as well as by other languages, obviously).
Line 29: Line 43:
Line 30: Line 45:
Line 33: Line 49:
Line 34: Line 51:
Line 37: Line 55:
Line 38: Line 57:
Line 41: Line 61:
Line 42: Line 63:
Line 45: Line 67:
Line 46: Line 69:


Line 49: Line 75:
For my part, I think this is something that the PSF should fund development on so that it happens sooner rather than later. There are enough interested parties, that lends itself to getting government or other grant funding. -- KevinAltis
Line 51: Line 76:
Having used the rexec stuff years ago (1995-6), I seem to recall that the principles of that module involved restricting the modules available, possibly along with the attributes available from each module, class and object. Is there a concise summary of how such mechanisms could have been subverted/exploited and a description of why they are particularly hard to fix? Or is that what this page is about? -- PaulBoddie For my part, I think this is something that the PSF should fund development on so that it happens sooner rather than later. There are enough interested parties, that lends itself to getting government or other grant funding. -- [[KevinAltis|KevinAltis]]
Line 53: Line 78:
I think it should be what the page is about. The basic problem is that Python's introspection allows several ways to "escape". For instance, code which is passed a file object, f, are given access to that single file, but it ALSO can use "type(f)", or "f.__class__" to get access to "file" itself, and then use it to open any file. Security experts will tell you that "plugging holes" is generally a poor approach to security because there usually turn out to be additional "holes" you hadn't considered -- true security requires an overall design with security considerations included. Doing this for Python is not impossible, but may prove difficult. On the other hand, I would agree that it is worthwhile. -- MichaelChermside
Line 55: Line 79:
I also have another idea... I have long thought that much of the issues could be handled by creating a module which would make it easy to run bits of Python code in a ''separate'' interpreter, running as a separate process, and sandboxed using OS features. The difficulty would be that such a module would require OS-specific code... but it would have the potential to provide sandboxing that was as reliable as the OS would allow. -- MichaelChermside Having used the rexec stuff years ago (1995-6), I seem to recall that the principles of that module involved restricting the modules available, possibly along with the attributes available from each module, class and object. Is there a concise summary of how such mechanisms could have been subverted/exploited and a description of why they are particularly hard to fix? Or is that what this page is about? -- [[PaulBoddie|PaulBoddie]]
Line 57: Line 81:
Sounds like Parrot, (PythonAndParrot,) to me. -- LionKimbro
Line 59: Line 82:
How so? -- MichaelChermside I think it should be what the page is about. The basic problem is that Python's introspection allows several ways to "escape". For instance, code which is passed a file object, f, are given access to that single file, but it ALSO can use "type(f)", or "f.class" to get access to "file" itself, and then use it to open any file. Security experts will tell you that "plugging holes" is generally a poor approach to security because there usually turn out to be additional "holes" you hadn't considered -- true security requires an overall design with security considerations included. Doing this for Python is not impossible, but may prove difficult. On the other hand, I would agree that it is worthwhile. -- [[MichaelChermside|MichaelChermside]]


I also have another idea... I have long thought that much of the issues could be handled by creating a module which would make it easy to run bits of Python code in a ''separate'' interpreter, running as a separate process, and sandboxed using OS features. The difficulty would be that such a module would require OS-specific code... but it would have the potential to provide sandboxing that was as reliable as the OS would allow. -- [[MichaelChermside|MichaelChermside]]


Sounds like Parrot, ([[PythonAndParrot|PythonAndParrot]],) to me. -- [[LionKimbro|LionKimbro]]


How so? -- [[MichaelChermside|MichaelChermside]]
Line 63: Line 96:
Parrot seems like a good target for running the sandboxed code in. I mean: ".NET" and all. Make it so you can secure the Parrot interpreter, and you're good. If a module requires custom C code links, or whatever, make it so you can close the gates to individual parts of C code, or something. And then make it so you can put various RestrictedExecution thingies on the Python code. -- LionKimbro
Line 65: Line 97:
Perhaps a better solution with the same approach would be [[Jython]]. Java provides excellent sandboxing capabilities, and [[Jython]] has the distinct advantage that it ''already exists and works''. -- MichaelChermside Parrot seems like a good target for running the sandboxed code in. I mean: ".NET" and all. Make it so you can secure the Parrot interpreter, and you're good. If a module requires custom C code links, or whatever, make it so you can close the gates to individual parts of C code, or something. And then make it so you can put various [[RestrictedExecution|RestrictedExecution]] thingies on the Python code. -- [[LionKimbro|LionKimbro]]
Line 67: Line 99:
 * As does [[http://boo.codehaus.org/|boo]], which runs on the .NET and Mono runtimes, which also have excellent sandboxing capabilities (I do not claim that they are any better than java, however). See [[http://www.gamedev.net/community/forums/topic.asp?topic_id=264462|this thread]] (you would have to convert the C# example posted by Viz''''''One to boo. There is a C# to boo converter in the boo add-in for the free Sharp''''''Develop IDE).
Line 69: Line 100:
Whereas Parrot; I think Parrot will function just fine. It'll just take a little time. -- LionKimbro <<DateTime(2004-05-07T16:54:04Z)>> Perhaps a better solution with the same approach would be [[Jython|Jython]]. Java provides excellent sandboxing capabilities, and [[Jython|Jython]] has the distinct advantage that it ''already exists and works''. -- [[MichaelChermside|MichaelChermside]]


 * As does [[http://boo.codehaus.org/|boo]], which runs on the .NET and Mono runtimes, which also have excellent sandboxing capabilities (I do not claim that they are any better than java, however). See [[http://www.gamedev.net/community/forums/topic.asp?topic_id=264462|this thread]] (you would have to convert the C# example posted by VizOne to boo. There is a C# to boo converter in the boo add-in for the free SharpDevelop IDE).


Whereas Parrot; I think Parrot will function just fine. It'll just take a little time. -- [[LionKimbro|LionKimbro]] 2004-05-07 16:54:04

Sandboxed Python

See also: How can I run an untrusted Python script safely (i.e. Sandbox) (from the Asking for Help page), Security.

Is there such a thing as "Sandboxed Python"? Something where you can run a Python that is limited in what it can do.

You could do all sorts of cool things with a sandboxed Python:

  • You could turn a wiki into an RAD development platform. You just draw up your interface with WikiSyntax, write up a little bit of Python code, and bam- instant application. :)

    • This is somewhat similar to TiddlyWiki - a JavaScript-based Wiki which behaves like a Web-based sandboxed application - although that approach utilises the JavaScript sandbox functionality in the Web browser, rather than accessing a sandboxed server-side application.

  • You could make a distributed code system, where not just resources, but functionality as well, can distribute safely over multiple computers.

Technical Mechanisms

A "Sandboxed Python" would let you permit or forbid modules, limit execution slices, permit or deny network traffic, constrain filesystem access to a particular directory (floated as "/"), and so on. It is also referred to as RestrictedExecution, a topic brought up by Mitch Kapor at PyCon and noted on his blog.

Related topics include capabilities as mentioned in PythonThreeDotOh, specifically this message on "capability-mediated modules". Some work has been done to support capabilities in languages with similar heritage to Python, notably CaPerl.

Implementation/Realisation Strategies

Some of these strategies were suggested in the discussion below.

Use Another Runtime

PyPy has support for creating a sandboxed Python interpreter. The Java and CLR/.NET runtimes support restricted execution, and these can be utilised through the Jython and IronPython variants of Python (as well as by other languages, obviously).

Use Operating System Support

Some operating systems support various levels of sandboxing, with the most extreme form being that of virtualisation or emulation. Yet UNIX-oriented operating systems also provide more lightweight mechanisms for restricting process behaviour such as chroot "jails", mandatory access controls, resource limits, and so on.

Modify the CPython Runtime

Whilst suggestions about removing functionality from CPython have been generally rejected either as being too simplistic and naive with regard to the possibilities to subvert Python's introspection mechanisms, or too restrictive with regard to support for commonly used modules or language features, it is at least reasonable to entertain the notion that a version of CPython linked to special system libraries and built without the more "powerful" or "unsafe" extensions (see Plash's sandboxing and libc call modifications for one approach) would not have the ability to perform arbitrary operations on the filesystem or network. Indeed, this is the basis on which operating systems are hosted within each other using various virtualisation technologies.

Use a Sandbox as an Accessory

In some cases, the functionality of untrusted code may be strictly defined. For example, mobile agent systems may, for the agents themselves, permit only a highly restricted style of program, or may only permit a very limited style of interaction with other components. One solution which can be considered within this particular domain is Zope's RestrictedPython - restricted subset of Python - although that solution focuses on reducing the level of expression in the language subset employed.

History

Prior to Python 2.3, there were two modules, rexec and Bastion which were attempted to provide a sandboxed environment. Unfortunately there were known bugs and work-arounds in these modules, and the introduction of new-style classes in Python 2.3 simply made matters worse. Rather than provide a false sense of security, the modules were removed in Python 2.3.

There are a number of people who are interested in creating a new sandboxing system for Python. Apart from the Zope RestrictedPython implementation, some work by Brett Cannon is ongoing, and related works such as mxProxy are also available (although the objectives of the latter and similar projects may be less ambitious than providing a full restricted execution environment).


Reactions

For my part, I think this is something that the PSF should fund development on so that it happens sooner rather than later. There are enough interested parties, that lends itself to getting government or other grant funding. -- KevinAltis

Having used the rexec stuff years ago (1995-6), I seem to recall that the principles of that module involved restricting the modules available, possibly along with the attributes available from each module, class and object. Is there a concise summary of how such mechanisms could have been subverted/exploited and a description of why they are particularly hard to fix? Or is that what this page is about? -- PaulBoddie

I think it should be what the page is about. The basic problem is that Python's introspection allows several ways to "escape". For instance, code which is passed a file object, f, are given access to that single file, but it ALSO can use "type(f)", or "f.class" to get access to "file" itself, and then use it to open any file. Security experts will tell you that "plugging holes" is generally a poor approach to security because there usually turn out to be additional "holes" you hadn't considered -- true security requires an overall design with security considerations included. Doing this for Python is not impossible, but may prove difficult. On the other hand, I would agree that it is worthwhile. -- MichaelChermside

I also have another idea... I have long thought that much of the issues could be handled by creating a module which would make it easy to run bits of Python code in a separate interpreter, running as a separate process, and sandboxed using OS features. The difficulty would be that such a module would require OS-specific code... but it would have the potential to provide sandboxing that was as reliable as the OS would allow. -- MichaelChermside

Sounds like Parrot, (PythonAndParrot,) to me. -- LionKimbro

How so? -- MichaelChermside

Oh, sorry. No, Parrot doesn't refer to running bits of Python code in a seperate interpreter.

Parrot seems like a good target for running the sandboxed code in. I mean: ".NET" and all. Make it so you can secure the Parrot interpreter, and you're good. If a module requires custom C code links, or whatever, make it so you can close the gates to individual parts of C code, or something. And then make it so you can put various RestrictedExecution thingies on the Python code. -- LionKimbro

Perhaps a better solution with the same approach would be Jython. Java provides excellent sandboxing capabilities, and Jython has the distinct advantage that it already exists and works. -- MichaelChermside

  • As does boo, which runs on the .NET and Mono runtimes, which also have excellent sandboxing capabilities (I do not claim that they are any better than java, however). See this thread (you would have to convert the C# example posted by VizOne to boo. There is a C# to boo converter in the boo add-in for the free SharpDevelop IDE).

Whereas Parrot; I think Parrot will function just fine. It'll just take a little time. -- LionKimbro 2004-05-07 16:54:04

SandboxedPython (last edited 2012-11-22 00:16:58 by d207-6-251-22)

Unable to edit the page? See the FrontPage for instructions.