1 ====================== 1 ======================
2 No New Privileges Flag 2 No New Privileges Flag
3 ====================== 3 ======================
4 4
5 The execve system call can grant a newly-start 5 The execve system call can grant a newly-started program privileges that
6 its parent did not have. The most obvious exa 6 its parent did not have. The most obvious examples are setuid/setgid
7 programs and file capabilities. To prevent th 7 programs and file capabilities. To prevent the parent program from
8 gaining these privileges as well, the kernel a 8 gaining these privileges as well, the kernel and user code must be
9 careful to prevent the parent from doing anyth 9 careful to prevent the parent from doing anything that could subvert the
10 child. For example: 10 child. For example:
11 11
12 - The dynamic loader handles ``LD_*`` environ 12 - The dynamic loader handles ``LD_*`` environment variables differently if
13 a program is setuid. 13 a program is setuid.
14 14
15 - chroot is disallowed to unprivileged proces 15 - chroot is disallowed to unprivileged processes, since it would allow
16 ``/etc/passwd`` to be replaced from the poi 16 ``/etc/passwd`` to be replaced from the point of view of a process that
17 inherited chroot. 17 inherited chroot.
18 18
19 - The exec code has special handling for ptra 19 - The exec code has special handling for ptrace.
20 20
21 These are all ad-hoc fixes. The ``no_new_priv 21 These are all ad-hoc fixes. The ``no_new_privs`` bit (since Linux 3.5) is a
22 new, generic mechanism to make it safe for a p 22 new, generic mechanism to make it safe for a process to modify its
23 execution environment in a manner that persist 23 execution environment in a manner that persists across execve. Any task
24 can set ``no_new_privs``. Once the bit is set 24 can set ``no_new_privs``. Once the bit is set, it is inherited across fork,
25 clone, and execve and cannot be unset. With ` 25 clone, and execve and cannot be unset. With ``no_new_privs`` set, ``execve()``
26 promises not to grant the privilege to do anyt 26 promises not to grant the privilege to do anything that could not have
27 been done without the execve call. For exampl 27 been done without the execve call. For example, the setuid and setgid
28 bits will no longer change the uid or gid; fil 28 bits will no longer change the uid or gid; file capabilities will not
29 add to the permitted set, and LSMs will not re 29 add to the permitted set, and LSMs will not relax constraints after
30 execve. 30 execve.
31 31
32 To set ``no_new_privs``, use:: 32 To set ``no_new_privs``, use::
33 33
34 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0); 34 prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
35 35
36 Be careful, though: LSMs might also not tighte 36 Be careful, though: LSMs might also not tighten constraints on exec
37 in ``no_new_privs`` mode. (This means that se 37 in ``no_new_privs`` mode. (This means that setting up a general-purpose
38 service launcher to set ``no_new_privs`` befor 38 service launcher to set ``no_new_privs`` before execing daemons may
39 interfere with LSM-based sandboxing.) 39 interfere with LSM-based sandboxing.)
40 40
41 Note that ``no_new_privs`` does not prevent pr 41 Note that ``no_new_privs`` does not prevent privilege changes that do not
42 involve ``execve()``. An appropriately privil 42 involve ``execve()``. An appropriately privileged task can still call
43 ``setuid(2)`` and receive SCM_RIGHTS datagrams 43 ``setuid(2)`` and receive SCM_RIGHTS datagrams.
44 44
45 There are two main use cases for ``no_new_priv 45 There are two main use cases for ``no_new_privs`` so far:
46 46
47 - Filters installed for the seccomp mode 2 sa 47 - Filters installed for the seccomp mode 2 sandbox persist across
48 execve and can change the behavior of newly 48 execve and can change the behavior of newly-executed programs.
49 Unprivileged users are therefore only allow 49 Unprivileged users are therefore only allowed to install such filters
50 if ``no_new_privs`` is set. 50 if ``no_new_privs`` is set.
51 51
52 - By itself, ``no_new_privs`` can be used to 52 - By itself, ``no_new_privs`` can be used to reduce the attack surface
53 available to an unprivileged user. If ever 53 available to an unprivileged user. If everything running with a
54 given uid has ``no_new_privs`` set, then th 54 given uid has ``no_new_privs`` set, then that uid will be unable to
55 escalate its privileges by directly attacki 55 escalate its privileges by directly attacking setuid, setgid, and
56 fcap-using binaries; it will need to compro 56 fcap-using binaries; it will need to compromise something without the
57 ``no_new_privs`` bit set first. 57 ``no_new_privs`` bit set first.
58 58
59 In the future, other potentially dangerous ker 59 In the future, other potentially dangerous kernel features could become
60 available to unprivileged tasks if ``no_new_pr 60 available to unprivileged tasks if ``no_new_privs`` is set. In principle,
61 several options to ``unshare(2)`` and ``clone( 61 several options to ``unshare(2)`` and ``clone(2)`` would be safe when
62 ``no_new_privs`` is set, and ``no_new_privs`` 62 ``no_new_privs`` is set, and ``no_new_privs`` + ``chroot`` is considerable less
63 dangerous than chroot by itself. 63 dangerous than chroot by itself.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.