[Python-Dev] Capabilities

[Guido van Rossum]

[Greg Ewing]
> I think I agree that to really get on top of this security business we
> need to move towards having dangerous things forbidden by default
> rather than allowed by default.

This is more or less what the rexec module implements, except for
convenience it has a list of unsafe built-ins rather than a list of
safe built-in.

> To that end, it would be useful if we could pin down exactly what's
> dangerous and what isn't.  It seems to me that most uses of
> introspection by most programs are harmless. Can we sort out those
> (hopefully few) things that are dangerous, and separate them from the
> existing introspection mechanisms?

Maybe, maybe not.  The original restricted execution code (not the
rexec module) arbitrarily decided that setting class attributes was
dangerous but getting them was not.  Samuele found that new-style
classes allow both, but always disallows write-access to the class
__dict__ (you have to use the setattr protocol); this is good or bad
depending on how it's used.

The real problem is that harmful access may be granted via
innocent-looking access.  For example, allowing read-only access to a
function's globals gives you access to the unrestricted 'open'
function...

> Access to sys.modules has been mentioned as a key thing that needs to
> be restricted. Maybe this shouldn't be an arbitrarily-accessible
> variable?  Maybe the sys module shouldn't be a module at all, but some
> special object that won't let you do nasty things with its contents
> unless you've got special privileges (which most code would *not*
> have by default). 

That's pretty much what the rexec module implements; it overrides
__import__ and when you ask for sys, you get a fake sys that only
contains stuff that should be safe.

> One of the "nasty" things would be picking the real __builtins__ out
> of sys.modules. Are there any others?

Picking an unsafe extension module out of sys.modules.

--Guido van Rossum (home page: http://www.python.org/~guido/)