How can Python code with no builtins reach os.system by walking __class__ and __subclasses__?

## The claim A common instinct is that you can run untrusted Python safely by handing it a namespace with the dangerous names removed — no `open`, no `__import__`, an emptied `__builtins__`. This leaf's job is to show *why that fails*, and the flagship technique is attribute traversal back to the builtins through `object.__subclasses__()`. ## Everything traces back to `object` Python's object model is a single connected graph. Every value has a type, reachable as `value.__class__`. Every type has bases, reachable as `type.__bases__` (or the full linearization `type.__mro__`). The root of every method-resolution order is the builtin `object`. So from *any* value the untrusted code can touch — a literal `()`, `''`, `0`, or an object you deliberately passed in — it can climb to `object`: ```python root = ().__class__.__bases__[0] # -> <class 'object'> # equivalently: ().__class__.__mro__[-1] ``` ## `object.__subclasses__()` is a menu of gadgets `object.__subclasses__()` returns a list of every class currently registered as a subclass of `object` anywhere in the interpreter — hundreds of them, including internal machinery from modules the host application imported. This list is a menu. The attacker walks it looking for a *gadget*: a class whose `__init__`, a method, or an attached function object has a `__globals__` mapping that already contains something dangerous — `os`, `subprocess`, `sys`, or `builtins` itself. A function object exposes its defining module's globals through `__globals__`, and those globals almost always include `__builtins__`. So a single gadget re-opens the entire builtins namespace you thought you had removed. The exact gadget varies by which modules are loaded, which is why real exploits enumerate rather than hard-code: ```python for cls in ().__class__.__bases__[0].__subclasses__(): g = getattr(getattr(cls, '__init__', None), '__globals__', {}) if 'os' in g or 'system' in g: pass # a usable gadget; call it to run a command ``` ## Why removing names does not help Restricting the execution namespace only controls which *names* resolve. It does nothing to the *attributes* already reachable from the objects in scope. `().__class__` does not consult your namespace — it is a slot on the object. `__bases__`, `__mro__`, `__subclasses__`, and `__globals__` are the same. Because the graph is redundant, blocking one edge is pointless: if you somehow removed `__subclasses__`, the attacker reaches the same modules through any function's `__globals__`, through `gc.get_objects()`, or through a frame's `f_globals`. There is no finite blacklist of attributes that seals the graph, because the graph is what the language *is*. ## What actually contains it The correct conclusion is architectural: you cannot sandbox untrusted Python inside the interpreter that runs your trusted code. Containment must be an operating-system boundary — a short-lived separate process with dropped privileges and resource limits, a container, or a virtual machine — so that even a full breakout inside the untrusted interpreter reaches nothing valuable and can be killed. Everything else (emptying `__builtins__`, auditing hooks, name blacklists) raises the effort bar slightly but is not a security boundary. ## Interview framing Interviewers ask this to see whether you understand that Python's dynamism is total: reflection is not an opt-in feature you can switch off, it is intrinsic. A candidate who says 'just delete the dangerous builtins' has not internalized the object model. The strong answer names the traversal (`__class__` -> `__bases__`/`__mro__` -> `object.__subclasses__()` -> a gadget's `__globals__`), explains why every mitigation at the namespace layer is bypassable, and lands on the process/container/VM boundary as the real answer.