no_new_privs.rst 2.9 KB

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