• Alexey Gladkov's avatar
    proc: allow to mount many instances of proc in one pid namespace · fa10fed3
    Alexey Gladkov authored
    This patch allows to have multiple procfs instances inside the
    same pid namespace. The aim here is lightweight sandboxes, and to allow
    that we have to modernize procfs internals.
    
    1) The main aim of this work is to have on embedded systems one
    supervisor for apps. Right now we have some lightweight sandbox support,
    however if we create pid namespacess we have to manages all the
    processes inside too, where our goal is to be able to run a bunch of
    apps each one inside its own mount namespace without being able to
    notice each other. We only want to use mount namespaces, and we want
    procfs to behave more like a real mount point.
    
    2) Linux Security Modules have multiple ptrace paths inside some
    subsystems, however inside procfs, the implementation does not guarantee
    that the ptrace() check which triggers the security_ptrace_check() hook
    will always run. We have the 'hidepid' mount option that can be used to
    force the ptrace_may_access() check inside has_pid_permissions() to run.
    The problem is that 'hidepid' is per pid namespace and not attached to
    the mount point, any remount or modification of 'hidepid' will propagate
    to all other procfs mounts.
    
    This also does not allow to support Yama LSM easily in desktop and user
    sessions. Yama ptrace scope which restricts ptrace and some other
    syscalls to be allowed only on inferiors, can be updated to have a
    per-task context, where the context will be inherited during fork(),
    clone() and preserved across execve(). If we support multiple private
    procfs instances, then we may force the ptrace_may_access() on
    /proc/<pids>/ to always run inside that new procfs instances. This will
    allow to specifiy on user sessions if we should populate procfs with
    pids that the user can ptrace or not.
    
    By using Yama ptrace scope, some restricted users will only be able to see
    inferiors inside /proc, they won't even be able to see their other
    processes. Some software like Chromium, Firefox's crash handler, Wine
    and others are already using Yama to restrict which processes can be
    ptracable. With this change this will give the possibility to restrict
    /proc/<pids>/ but more importantly this will give desktop users a
    generic and usuable way to specifiy which users should see all processes
    and which users can not.
    
    Side notes:
    * This covers the lack of seccomp where it is not able to parse
    arguments, it is easy to install a seccomp filter on direct syscalls
    that operate on pids, however /proc/<pid>/ is a Linux ABI using
    filesystem syscalls. With this change LSMs should be able to analyze
    open/read/write/close...
    
    In the new patch set version I removed the 'newinstance' option
    as suggested by Eric W. Biederman.
    
    Selftest has been added to verify new behavior.
    Signed-off-by: default avatarAlexey Gladkov <gladkov.alexey@gmail.com>
    Reviewed-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
    Reviewed-by: default avatarKees Cook <keescook@chromium.org>
    Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
    fa10fed3
proc-multiple-procfs.c 1.56 KB