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