64 lines · plain
1======================2No New Privileges Flag3======================4 5The execve system call can grant a newly-started program privileges that6its parent did not have. The most obvious examples are setuid/setgid7programs and file capabilities. To prevent the parent program from8gaining these privileges as well, the kernel and user code must be9careful to prevent the parent from doing anything that could subvert the10child. For example:11 12 - The dynamic loader handles ``LD_*`` environment variables differently if13 a program is setuid.14 15 - chroot is disallowed to unprivileged processes, since it would allow16 ``/etc/passwd`` to be replaced from the point of view of a process that17 inherited chroot.18 19 - The exec code has special handling for ptrace.20 21These are all ad-hoc fixes. The ``no_new_privs`` bit (since Linux 3.5) is a22new, generic mechanism to make it safe for a process to modify its23execution environment in a manner that persists across execve. Any task24can set ``no_new_privs``. Once the bit is set, it is inherited across fork,25clone, and execve and cannot be unset. With ``no_new_privs`` set, ``execve()``26promises not to grant the privilege to do anything that could not have27been done without the execve call. For example, the setuid and setgid28bits will no longer change the uid or gid; file capabilities will not29add to the permitted set, and LSMs will not relax constraints after30execve.31 32To set ``no_new_privs``, use::33 34 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);35 36Be careful, though: LSMs might also not tighten constraints on exec37in ``no_new_privs`` mode. (This means that setting up a general-purpose38service launcher to set ``no_new_privs`` before execing daemons may39interfere with LSM-based sandboxing.)40 41Note that ``no_new_privs`` does not prevent privilege changes that do not42involve ``execve()``. An appropriately privileged task can still call43``setuid(2)`` and receive SCM_RIGHTS datagrams.44 45There are two main use cases for ``no_new_privs`` so far:46 47 - Filters installed for the seccomp mode 2 sandbox persist across48 execve and can change the behavior of newly-executed programs.49 Unprivileged users are therefore only allowed to install such filters50 if ``no_new_privs`` is set.51 52 - By itself, ``no_new_privs`` can be used to reduce the attack surface53 available to an unprivileged user. If everything running with a54 given uid has ``no_new_privs`` set, then that uid will be unable to55 escalate its privileges by directly attacking setuid, setgid, and56 fcap-using binaries; it will need to compromise something without the57 ``no_new_privs`` bit set first.58 59In the future, other potentially dangerous kernel features could become60available to unprivileged tasks if ``no_new_privs`` is set. In principle,61several options to ``unshare(2)`` and ``clone(2)`` would be safe when62``no_new_privs`` is set, and ``no_new_privs`` + ``chroot`` is considerable less63dangerous than chroot by itself.64