• A
    Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs · 259e5e6c
    Andy Lutomirski 提交于
    With this change, calling
      prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
    disables privilege granting operations at execve-time.  For example, a
    process will not be able to execute a setuid binary to change their uid
    or gid if this bit is set.  The same is true for file capabilities.
    
    Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that
    LSMs respect the requested behavior.
    
    To determine if the NO_NEW_PRIVS bit is set, a task may call
      prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
    It returns 1 if set and 0 if it is not set. If any of the arguments are
    non-zero, it will return -1 and set errno to -EINVAL.
    (PR_SET_NO_NEW_PRIVS behaves similarly.)
    
    This functionality is desired for the proposed seccomp filter patch
    series.  By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the
    system call behavior for itself and its child tasks without being
    able to impact the behavior of a more privileged task.
    
    Another potential use is making certain privileged operations
    unprivileged.  For example, chroot may be considered "safe" if it cannot
    affect privileged tasks.
    
    Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is
    set and AppArmor is in use.  It is fixed in a subsequent patch.
    Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
    Signed-off-by: NWill Drewry <wad@chromium.org>
    Acked-by: NEric Paris <eparis@redhat.com>
    Acked-by: NKees Cook <keescook@chromium.org>
    
    v18: updated change desc
    v17: using new define values as per 3.4
    Signed-off-by: NJames Morris <james.l.morris@oracle.com>
    259e5e6c
sys.c 47.3 KB