[Python-Dev] Internal namespace proposal (original) (raw)

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Fri Jul 28 03:40:53 CEST 2006

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>

More information about the Python-Dev mailing list