[Python-Dev] new security doc using object-capabilities

[Michael Foord]

Brett Cannon wrote:
> 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 
> <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.
>

This may not be relevant or  possible, in which case I apologise, but 
the .NET model of creating application domains is extremely useful. It 
allows you to assign domains and run code within those domains. This 
means, for example, you can create a plugin system and run the plugins 
in a secure domain.

I realise that this was the intent of the original rexec module, and 
your proposed new design (which is very exciting) overcomes the 
difficulties in that approach. The only approach using the new system 
would be interprocess communication (?) with a trusted interpreter 
communicating with an un-trusted one. Would the communication layer need 
to be implemented as a C extension, or will a standard Python API be 
possible ? Hmmm.... maybe I should read your doc. :-)

Michael Foord
http://www.voidspace.org.uk/python/index.shtml

> 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
> ------------------------------------------------------------------------
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>