[Python-Dev] Capabilities

[Samuele Pedroni]

From: "Guido van Rossum" <guido@python.org>
> [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.

but given that methods can be overriden per instance with classic-classes:

class C:
  def f(s):
    ...

c=C()
c.f = lambda s: s

it was not so effective.

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

restricted execution alone for example does not have a notion of subclassable
vs. non subclassable classes,
and given its approach, subclassing can be dangerous.

For sure a good thing would be for func_* and im_* attributes of functions and
methods to be substituted by special accessor functions/objects, indipendently
of restricted mode.

Function and method should be for normal code basically opaque.