• Andy Lutomirski's avatar
    fs: Treat foreign mounts as nosuid · 380cf5ba
    Andy Lutomirski authored
    If a process gets access to a mount from a different user
    namespace, that process should not be able to take advantage of
    setuid files or selinux entrypoints from that filesystem.  Prevent
    this by treating mounts from other mount namespaces and those not
    owned by current_user_ns() or an ancestor as nosuid.
    
    This will make it safer to allow more complex filesystems to be
    mounted in non-root user namespaces.
    
    This does not remove the need for MNT_LOCK_NOSUID.  The setuid,
    setgid, and file capability bits can no longer be abused if code in
    a user namespace were to clear nosuid on an untrusted filesystem,
    but this patch, by itself, is insufficient to protect the system
    from abuse of files that, when execed, would increase MAC privilege.
    
    As a more concrete explanation, any task that can manipulate a
    vfsmount associated with a given user namespace already has
    capabilities in that namespace and all of its descendents.  If they
    can cause a malicious setuid, setgid, or file-caps executable to
    appear in that mount, then that executable will only allow them to
    elevate privileges in exactly the set of namespaces in which they
    are already privileges.
    
    On the other hand, if they can cause a malicious executable to
    appear with a dangerous MAC label, running it could change the
    caller's security context in a way that should not have been
    possible, even inside the namespace in which the task is confined.
    
    As a hardening measure, this would have made CVE-2014-5207 much
    more difficult to exploit.
    Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
    Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
    Acked-by: default avatarJames Morris <james.l.morris@oracle.com>
    Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
    Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
    380cf5ba
commoncap.c 31.6 KB