[lkml]   [1998]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:42    [W:0.079 / U:1.776 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site