diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2017-07-03 21:13:25 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2017-07-03 21:13:25 -0700 |
commit | 650fc870a2ef35b83397eebd35b8c8df211bff78 (patch) | |
tree | 14a293fa894d0f166aa60f1f5ca672a2bdb312c0 /Documentation/userspace-api/no_new_privs.rst | |
parent | f4dd029ee0b92b77769a1ac6dce03e829e74763e (diff) | |
parent | 1cb566ba5634d7593b8b2a0a5c83f1c9e14b2e09 (diff) | |
download | blackbird-obmc-linux-650fc870a2ef35b83397eebd35b8c8df211bff78.tar.gz blackbird-obmc-linux-650fc870a2ef35b83397eebd35b8c8df211bff78.zip |
Merge tag 'docs-4.13' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet:
"There has been a fair amount of activity in the docs tree this time
around. Highlights include:
- Conversion of a bunch of security documentation into RST
- The conversion of the remaining DocBook templates by The Amazing
Mauro Machine. We can now drop the entire DocBook build chain.
- The usual collection of fixes and minor updates"
* tag 'docs-4.13' of git://git.lwn.net/linux: (90 commits)
scripts/kernel-doc: handle DECLARE_HASHTABLE
Documentation: atomic_ops.txt is core-api/atomic_ops.rst
Docs: clean up some DocBook loose ends
Make the main documentation title less Geocities
Docs: Use kernel-figure in vidioc-g-selection.rst
Docs: fix table problems in ras.rst
Docs: Fix breakage with Sphinx 1.5 and upper
Docs: Include the Latex "ifthen" package
doc/kokr/howto: Only send regression fixes after -rc1
docs-rst: fix broken links to dynamic-debug-howto in kernel-parameters
doc: Document suitability of IBM Verse for kernel development
Doc: fix a markup error in coding-style.rst
docs: driver-api: i2c: remove some outdated information
Documentation: DMA API: fix a typo in a function name
Docs: Insert missing space to separate link from text
doc/ko_KR/memory-barriers: Update control-dependencies example
Documentation, kbuild: fix typo "minimun" -> "minimum"
docs: Fix some formatting issues in request-key.rst
doc: ReSTify keys-trusted-encrypted.txt
doc: ReSTify keys-request-key.txt
...
Diffstat (limited to 'Documentation/userspace-api/no_new_privs.rst')
-rw-r--r-- | Documentation/userspace-api/no_new_privs.rst | 63 |
1 files changed, 63 insertions, 0 deletions
diff --git a/Documentation/userspace-api/no_new_privs.rst b/Documentation/userspace-api/no_new_privs.rst new file mode 100644 index 000000000000..d060ea217ea1 --- /dev/null +++ b/Documentation/userspace-api/no_new_privs.rst @@ -0,0 +1,63 @@ +====================== +No New Privileges Flag +====================== + +The execve system call can grant a newly-started program privileges that +its parent did not have. The most obvious examples are setuid/setgid +programs and file capabilities. To prevent the parent program from +gaining these privileges as well, the kernel and user code must be +careful to prevent the parent from doing anything that could subvert the +child. For example: + + - The dynamic loader handles ``LD_*`` environment variables differently if + a program is setuid. + + - chroot is disallowed to unprivileged processes, since it would allow + ``/etc/passwd`` to be replaced from the point of view of a process that + inherited chroot. + + - The exec code has special handling for ptrace. + +These are all ad-hoc fixes. The ``no_new_privs`` bit (since Linux 3.5) is a +new, generic mechanism to make it safe for a process to modify its +execution environment in a manner that persists across execve. Any task +can set ``no_new_privs``. Once the bit is set, it is inherited across fork, +clone, and execve and cannot be unset. With ``no_new_privs`` set, ``execve()`` +promises not to grant the privilege to do anything that could not have +been done without the execve call. For example, the setuid and setgid +bits will no longer change the uid or gid; file capabilities will not +add to the permitted set, and LSMs will not relax constraints after +execve. + +To set ``no_new_privs``, use:: + + prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0); + +Be careful, though: LSMs might also not tighten constraints on exec +in ``no_new_privs`` mode. (This means that setting up a general-purpose +service launcher to set ``no_new_privs`` before execing daemons may +interfere with LSM-based sandboxing.) + +Note that ``no_new_privs`` does not prevent privilege changes that do not +involve ``execve()``. An appropriately privileged task can still call +``setuid(2)`` and receive SCM_RIGHTS datagrams. + +There are two main use cases for ``no_new_privs`` so far: + + - Filters installed for the seccomp mode 2 sandbox persist across + execve and can change the behavior of newly-executed programs. + Unprivileged users are therefore only allowed to install such filters + if ``no_new_privs`` is set. + + - By itself, ``no_new_privs`` can be used to reduce the attack surface + available to an unprivileged user. If everything running with a + given uid has ``no_new_privs`` set, then that uid will be unable to + escalate its privileges by directly attacking setuid, setgid, and + fcap-using binaries; it will need to compromise something without the + ``no_new_privs`` bit set first. + +In the future, other potentially dangerous kernel features could become +available to unprivileged tasks if ``no_new_privs`` is set. In principle, +several options to ``unshare(2)`` and ``clone(2)`` would be safe when +``no_new_privs`` is set, and ``no_new_privs`` + ``chroot`` is considerable less +dangerous than chroot by itself. |