[Python-Dev] ANNOUNCE: CapPython, an object-capability subset of Python

Mark Seaborn mrs at mythic-beasts.com
Thu Sep 18 19:09:52 CEST 2008


During the past couple of months I have been working on an
object-capability subset of Python - in other words, a restricted
execution scheme for sandboxing Python code.  It has been influenced
by other object-capability subset languages, such as Joe-E (a subset
of Java [1]), Caja/Cajita (subsets of Javascript [2]) and Caperl
(based on Perl [3]).  I'm calling it CapPython because the name
doesn't seem to have been taken yet. :-)

I believe it is now secure, so it seems like a good time to announce
it here!

The basic idea behind CapPython is to enforce encapsulation by
restricting access to private attributes of objects.  This is achieved
through a combination of static checking and limiting access to unsafe
builtins and modules.

Private attributes may only be accessed through "self" variables.
"Self" variables are defined as being the first arguments of functions
defined inside class definitions, with a few restrictions intended to
prevent these functions from escaping without being safely wrapped.
Private attribute names are those starting with "_".  Additionally,
"im_self", "im_func" and some other special cases are treated as
private attributes.  Assignments to attributes are only allowed via
"self" variables.

For example, the following code is accepted by the static verifier:

class Counter(object):
    def __init__(self):
        self._count = 0
    def get_next(self):
        self._count += 1
        return self._count

But the following code reads a private attribute and so it is rejected
as violating encapsulation:

counter._count -= 1

CapPython consists of three parts:
 - a static verifier;
 - a "safe exec" function, which will check code before executing it and
   can run code in a safe scope;
 - a module loader which implements a safe __import__ function.  Eventually
   this will be runnable as untrusted CapPython code.

I am documenting CapPython via my blog at the moment, with the
following posts so far:
http://lackingrhoticity.blogspot.com/2008/08/introducing-cappython.html
http://lackingrhoticity.blogspot.com/2008/09/dealing-with-modules-and-builtins-in.html
http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html

The code is available from a Bazaar repository on Launchpad:
https://code.launchpad.net/cappython

I am currently working on creating a simple example program, which
will be a wsgiref-based web server with a form for executing CapPython
code.  This involves taming some of the standard libraries to pass the
verifier.

There are some design notes here -
http://plash.beasts.org/wiki/CapPython
- although these notes are more a list of references and problems
CapPython needs to address than an explanation of the current design.
There was also a thread about CapPython on the e-lang mailing list:
http://www.eros-os.org/pipermail/e-lang/2008-August/012828.html

Mark

[1] http://code.google.com/p/joe-e/
[2] http://code.google.com/p/google-caja/
[3] http://caperl.links.org/


More information about the Python-Dev mailing list