1*40fde647SKees Cook====================== 2*40fde647SKees CookNo New Privileges Flag 3*40fde647SKees Cook====================== 4*40fde647SKees Cook 5*40fde647SKees CookThe execve system call can grant a newly-started program privileges that 6*40fde647SKees Cookits parent did not have. The most obvious examples are setuid/setgid 7*40fde647SKees Cookprograms and file capabilities. To prevent the parent program from 8*40fde647SKees Cookgaining these privileges as well, the kernel and user code must be 9*40fde647SKees Cookcareful to prevent the parent from doing anything that could subvert the 10*40fde647SKees Cookchild. For example: 11*40fde647SKees Cook 12*40fde647SKees Cook - The dynamic loader handles ``LD_*`` environment variables differently if 13*40fde647SKees Cook a program is setuid. 14*40fde647SKees Cook 15*40fde647SKees Cook - chroot is disallowed to unprivileged processes, since it would allow 16*40fde647SKees Cook ``/etc/passwd`` to be replaced from the point of view of a process that 17*40fde647SKees Cook inherited chroot. 18*40fde647SKees Cook 19*40fde647SKees Cook - The exec code has special handling for ptrace. 20*40fde647SKees Cook 21*40fde647SKees CookThese are all ad-hoc fixes. The ``no_new_privs`` bit (since Linux 3.5) is a 22*40fde647SKees Cooknew, generic mechanism to make it safe for a process to modify its 23*40fde647SKees Cookexecution environment in a manner that persists across execve. Any task 24*40fde647SKees Cookcan set ``no_new_privs``. Once the bit is set, it is inherited across fork, 25*40fde647SKees Cookclone, and execve and cannot be unset. With ``no_new_privs`` set, ``execve()`` 26*40fde647SKees Cookpromises not to grant the privilege to do anything that could not have 27*40fde647SKees Cookbeen done without the execve call. For example, the setuid and setgid 28*40fde647SKees Cookbits will no longer change the uid or gid; file capabilities will not 29*40fde647SKees Cookadd to the permitted set, and LSMs will not relax constraints after 30*40fde647SKees Cookexecve. 31*40fde647SKees Cook 32*40fde647SKees CookTo set ``no_new_privs``, use:: 33*40fde647SKees Cook 34*40fde647SKees Cook prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0); 35*40fde647SKees Cook 36*40fde647SKees CookBe careful, though: LSMs might also not tighten constraints on exec 37*40fde647SKees Cookin ``no_new_privs`` mode. (This means that setting up a general-purpose 38*40fde647SKees Cookservice launcher to set ``no_new_privs`` before execing daemons may 39*40fde647SKees Cookinterfere with LSM-based sandboxing.) 40*40fde647SKees Cook 41*40fde647SKees CookNote that ``no_new_privs`` does not prevent privilege changes that do not 42*40fde647SKees Cookinvolve ``execve()``. An appropriately privileged task can still call 43*40fde647SKees Cook``setuid(2)`` and receive SCM_RIGHTS datagrams. 44*40fde647SKees Cook 45*40fde647SKees CookThere are two main use cases for ``no_new_privs`` so far: 46*40fde647SKees Cook 47*40fde647SKees Cook - Filters installed for the seccomp mode 2 sandbox persist across 48*40fde647SKees Cook execve and can change the behavior of newly-executed programs. 49*40fde647SKees Cook Unprivileged users are therefore only allowed to install such filters 50*40fde647SKees Cook if ``no_new_privs`` is set. 51*40fde647SKees Cook 52*40fde647SKees Cook - By itself, ``no_new_privs`` can be used to reduce the attack surface 53*40fde647SKees Cook available to an unprivileged user. If everything running with a 54*40fde647SKees Cook given uid has ``no_new_privs`` set, then that uid will be unable to 55*40fde647SKees Cook escalate its privileges by directly attacking setuid, setgid, and 56*40fde647SKees Cook fcap-using binaries; it will need to compromise something without the 57*40fde647SKees Cook ``no_new_privs`` bit set first. 58*40fde647SKees Cook 59*40fde647SKees CookIn the future, other potentially dangerous kernel features could become 60*40fde647SKees Cookavailable to unprivileged tasks if ``no_new_privs`` is set. In principle, 61*40fde647SKees Cookseveral options to ``unshare(2)`` and ``clone(2)`` would be safe when 62*40fde647SKees Cook``no_new_privs`` is set, and ``no_new_privs`` + ``chroot`` is considerable less 63*40fde647SKees Cookdangerous than chroot by itself. 64