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

[Michael Foord]

Michael Foord wrote:
> 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. :-)
>
>   
Ok, started to read the doc - and realise it specifically addresses 
these issues. My apologies :-)

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

> 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
>>   
>>     
>
> _______________________________________________
> 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
>
>