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/%7Eguido/)