[Python-Dev] Internal namespace proposal

[David Hopwood]

Greg Ewing wrote:
> David Hopwood wrote:
> 
>> Inheritance should be defined as though the code of inherited methods and
>> attributes were copied into the subclass (with global accesses updated to
>> point to the original module).
> 
> You'll have to propose an implementation strategy for that
> which works without actually copying all the code, though.

The only difference between the copying semantics and the current semantics,
is in the visibility of module-global internal variables and functions. It's
sufficient to keep track of whether each class could access a variable or function
that is internal to its module. If it does, then it cannot be subclassed from
a different module. (It must not be possible to access internal variables/
functions reflectively.)

The effect of this is that if a programmer intends a class to be subclassable
from outside the module, they must make sure that all of the variables/functions
it depends on are public. Anyone performing a security review of the module then
does not have to consider inheritance from a different module when deciding
which variables/functions might be accessible.


There is a slightly more flexible version of this approach that is just as
secure, provided that functions are restricted to be stateless. If it is
possible to prove statically that a class does not access any internal
*variables* of a module (regardless of whether it accesses internal functions),
then it is safe to allow the class to be subclassed from another module. This
is because the subclassing module could have copied all of the code of the
original module (assuming it is written purely in Python); the only possible
sources of authority in a capability language are from access to variables or
primitives, not code.


If a class is not written in Python, then we cannot analyse whether it accesses
internal variables. In that case the class will be part of the TCB, and we have
to trust the class writer to mark whether it can be safely subclassed from
another module.

>> Since x._hidden is not accessible from attack.py, the attack fails.
> 
> But if _hidden were an attribute of the A instance that
> you were trying to protect, it would succeed.

No, attack.py could only access a _hidden attribute in an instance of B.
This is harmless, because it could just as well define the _hidden attribute
of B itself, rather than by subclassing.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>