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@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@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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
