[Python-Dev] Capabilities

[Greg Ewing]

Guido:

> That flag wasn't my idea, it was some one else's (Greg Ewing?).

Yes, it was my idea. I was thinking that there was already a word of
flags in the object struct that might have some room left, but I may
have been thinking of type objects.

I'm not sure it's such a good idea now anyway.  As has been pointed
out, you'd still need proxies of some kind to restrict interfaces. It
would just mean you'd be able to build your proxy out of any suitable
type of object.

The other idea was that trusted code would be able to set the flag on
all the objects that it passed to untrusted code, instead of having to
proxy them all. But, as has also been pointed out, that's a rather
brittle way to enforce security.

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.

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?

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). 

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

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+