It's not possible to prevent root (uid 0) from escaping from a chrooted
cell - that's not the intention of this patch. The only way to prevent
root from escaping is to remove root's powers. There are already
efforts underway to fix this by adding a more finely grained capability
system. I'm not going to reinvent that work.
The intention is to stop ordinary, non-root processes from escaping. In
traditional Unix, chroot is a quite effective mechanism for isolating
potentially untrusted processes from the rest of the filesystem. Under
Linux this is weakened by /proc, which allows ordinary processes an
escape path to the rest of the system. You can prevent this by making
sure that uids used in the chroot jail are distinct from uids elsewhere,
but this is cumbersome and fragile.
This patch merely enforces the original guarentee of chroot - a process
can't escape from a chrooted jail. It doesn't add any further
guarentees: you can still send signals, use ptrace, allocate all the
memory, fill the filesystem. It doesn't prevent root from mounting
filesystems, creating device nodes, loading kernel modules, opening
/dev/mem or anything else. This patch does not enforce policy; it just
makes sure the chroot mechanism is still effective.
It also doesn't change the semantics of any other syscall. It would be
possible to use the same test to authorize sending signals, using ptrace
and so on, but that would be a change to syscall semantics. I suspect
they would be desireable and mostly harmless, but this is a
conservative patch.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu