[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.021 / U:8.004 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site