tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
doc: ReSTify no_new_privs.txt
This updates no_new_privs documentation to ReST markup and adds it to
the user-space API documentation.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
authored by
Kees Cook
and committed by
Jonathan Corbet
40fde647
c061f33f
+26
-19
+25
-19
Documentation/prctl/no_new_privs.txt
Documentation/userspace-api/no_new_privs.rst
+25
-19
Documentation/prctl/no_new_privs.txt
Documentation/userspace-api/no_new_privs.rst
···
1
+
======================
2
+
No New Privileges Flag
3
+
======================
4
+
1
5
The execve system call can grant a newly-started program privileges that
2
6
its parent did not have. The most obvious examples are setuid/setgid
3
7
programs and file capabilities. To prevent the parent program from
···
9
5
careful to prevent the parent from doing anything that could subvert the
10
6
child. For example:
11
7
12
-
- The dynamic loader handles LD_* environment variables differently if
8
+
- The dynamic loader handles ``LD_*`` environment variables differently if
13
9
a program is setuid.
14
10
15
11
- chroot is disallowed to unprivileged processes, since it would allow
16
-
/etc/passwd to be replaced from the point of view of a process that
12
+
``/etc/passwd`` to be replaced from the point of view of a process that
17
13
inherited chroot.
18
14
19
15
- The exec code has special handling for ptrace.
20
16
21
-
These are all ad-hoc fixes. The no_new_privs bit (since Linux 3.5) is a
17
+
These are all ad-hoc fixes. The ``no_new_privs`` bit (since Linux 3.5) is a
22
18
new, generic mechanism to make it safe for a process to modify its
23
19
execution environment in a manner that persists across execve. Any task
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 no_new_privs set, execve
20
+
can set ``no_new_privs``. Once the bit is set, it is inherited across fork,
21
+
clone, and execve and cannot be unset. With ``no_new_privs`` set, ``execve()``
26
22
promises not to grant the privilege to do anything that could not have
27
23
been done without the execve call. For example, the setuid and setgid
28
24
bits will no longer change the uid or gid; file capabilities will not
29
25
add to the permitted set, and LSMs will not relax constraints after
30
26
execve.
31
27
32
-
To set no_new_privs, use prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0).
28
+
To set ``no_new_privs``, use::
29
+
30
+
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
33
31
34
32
Be careful, though: LSMs might also not tighten constraints on exec
35
-
in no_new_privs mode. (This means that setting up a general-purpose
36
-
service launcher to set no_new_privs before execing daemons may
33
+
in ``no_new_privs`` mode. (This means that setting up a general-purpose
34
+
service launcher to set ``no_new_privs`` before execing daemons may
37
35
interfere with LSM-based sandboxing.)
38
36
39
-
Note that no_new_privs does not prevent privilege changes that do not
40
-
involve execve. An appropriately privileged task can still call
41
-
setuid(2) and receive SCM_RIGHTS datagrams.
37
+
Note that ``no_new_privs`` does not prevent privilege changes that do not
38
+
involve ``execve()``. An appropriately privileged task can still call
39
+
``setuid(2)`` and receive SCM_RIGHTS datagrams.
42
40
43
-
There are two main use cases for no_new_privs so far:
41
+
There are two main use cases for ``no_new_privs`` so far:
44
42
45
43
- Filters installed for the seccomp mode 2 sandbox persist across
46
44
execve and can change the behavior of newly-executed programs.
47
45
Unprivileged users are therefore only allowed to install such filters
48
-
if no_new_privs is set.
46
+
if ``no_new_privs`` is set.
49
47
50
-
- By itself, no_new_privs can be used to reduce the attack surface
48
+
- By itself, ``no_new_privs`` can be used to reduce the attack surface
51
49
available to an unprivileged user. If everything running with a
52
-
given uid has no_new_privs set, then that uid will be unable to
50
+
given uid has ``no_new_privs`` set, then that uid will be unable to
53
51
escalate its privileges by directly attacking setuid, setgid, and
54
52
fcap-using binaries; it will need to compromise something without the
55
-
no_new_privs bit set first.
53
+
``no_new_privs`` bit set first.
56
54
57
55
In the future, other potentially dangerous kernel features could become
58
-
available to unprivileged tasks if no_new_privs is set. In principle,
59
-
several options to unshare(2) and clone(2) would be safe when
60
-
no_new_privs is set, and no_new_privs + chroot is considerable less
56
+
available to unprivileged tasks if ``no_new_privs`` is set. In principle,
57
+
several options to ``unshare(2)`` and ``clone(2)`` would be safe when
58
+
``no_new_privs`` is set, and ``no_new_privs`` + ``chroot`` is considerable less
61
59
dangerous than chroot by itself.