Messages in this thread | | | Date | Wed, 01 Apr 1998 10:49:08 +1000 | From | Jeremy Fitzhardinge <> | Subject | Re: Security patch for /proc |
| |
Chris Evans wrote: > I'm not sure I agree with this approach -- perhaps root processes should > not be allowed to use the mount() syscall if root_dir != real_root. The > other main source of nastiness is ptrace() -- this needs to be banned in a > similar manner. There are other ways root could escape a chroot() > jail, we need to think about them and eliminate them one by one.
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
| |