[cap-talk] Brett proposes object-capabilities for Python

[Brett Cannon]

On 7/19/06, Ka-Ping Yee <cap-talk at zesty.ca> wrote:
>
> OMG!!!  Is all i can say at the moment.  Very excited.


=)  Here is to hoping it goes smoothly and quickly.

If people have questions feel free to ask here or me personally.  The doc
referenced in my email to python-dev is geared toward the python-dev crowd,
so it introduces object-capabilities with kid gloves plus some Python
specifics.

Also realize that I am using object-capabilities to secure the interpreter,
not objects.  That will be enough of a challenge to do for now.  Who knows,
maybe some day Python can support object-capabilities at the object level,
but for now I am just trying to isolate and protect individual interpreters
in the same process.

-Brett


-- ?!ng
>
>
> ---------- Forwarded message ----------
> Date: Wed, 19 Jul 2006 15:35:45 -0700
> From: Brett Cannon <brett at python.org>
> To: Python Dev <python-dev at python.org>
> Subject: [Python-Dev] new security doc using object-capabilities
>
> After various people suggesting object-capabilities, takling with Mark S.
> Miller of the E programming language, and the people Mark works with at HP
> Labs (who have been giving talks every week during this month here at
> Google
> on object-capabilities), I have decided to go with object-capabilities for
> securing interpreters.  I have rewritten my design doc from scratch and
> deleted the old one.  The new doc is named securing_python.txt and can be
> found through the svn web interface at
>
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717&view=log
> .
> I have pretty much ignored any concrete API and such and gone more
> with a
> conceptual doc to make sure the API does not get in the way of the core
> security model.
>
> Using object-capabilities should make the implementation much cleaner.
> There is much less work directly on the interpreter and more of it gets
> pushed up to extension modules.  I also have the okay of my supervisor to
> use this approach in my dissertation so this will get done.
>
> Two things do fall out of all of this which will make development much
> more
> modular and easier.  First, the memory cap work just becomes a special
> build
> on its own; no need to tie into the security work.  So I will be cleaning
> up
> the bcannon-sandboxing branch code as it stands, and then either create a
> separate branch for the object-capabilities work, or create another branch
> for the memory cap stuff and shift the changes over there.  I will most
> likely do the former so as to not lose the history on the checkins.
>
> I also plan to rewrite the import machinery in pure Python.  This will
> make
> the code much more maintainable and make creating proxies for the import
> machinery much easier.  I will be doing that in a directory in the sandbox
> initially since it needs to work from what Python has now (and possibly
> some
> new extension module code) before it can be integrated into the
> interpreter
> directly.  Anyone who wants to help with that can.  I already have some
> perliminary notes on the whole thing and I think it will be reasonably
> doable.
>
> Anyway, there you go.  Here is to hoping I have thought this all through
> properly.  =)
>
> -Brett
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20060719/00b8e87c/attachment.html