[Python-Dev] rexec.py unuseable

[Nick Coghlan]

Luke Kenneth Casson Leighton wrote:
>  in some ways, the longer this is left, the harder it is going to
>  be to retrospectively bolt on.
> 
>  there's an adage that says security cannot be easily added in, it
>  has to be designed in from the start.

This is very true, but it hurts an ACL-based approach even worse than it 
hurts a capabilities based one.

To get capabilities to work, the question is: how do we construct an 
environment where 'builtins' and all other objects passed to code in 
that environment have been suitably restricted to prevent malicious code 
from causing damage.

The original objects, which are never made available to the untrusted 
code, don't need to care about trust issues - they just keep working as 
they always have.

To get ACL's to work, _everything_ in Python has to care about trust 
issues, as they have to know that they should be checking for the 
existence of an ACL.

I can't even begin to imagine how those ACL's might be managed 
effectively, but I can imagine constructing a special execution 
environment which only allowed 'safe' objects to be passed in.

A 'safe' object would be one of the restricted builtins, or objects able 
to be constructed using only that restricted set of builtins. The major 
issue comes in dealing with Python's introspection capabilities without 
making them completely useless (then again, perhaps 'restricted, with 
almost no introspection' would be an improvement over 'no restricted mode'.

Anyway, despite either approach being Python 3.0 material, the 
capability method at least seems conceptually possible - deleting 
entries out of Python namespace dictionaries is a fairly straightforward 
activity, as is substituting a new implementation for the old 'unsafe' 
implementation when we want to switch to 'restricted' mode. Whereas 
handling ACL's would be a completely new approach that spreads its 
tentacles through much of the CPython source code.

For code, capabilities just make more sense - if they can't use it, 
don't even let them know it's there.

Cheers,
Nick.

-- 
Nick Coghlan               |     Brisbane, Australia
Email: ncoghlan at email.com  | Mobile: +61 409 573 268