security: Minor improvements to no_new_privs documentation

The documentation didn't actually mention how to enable no_new_privs. This also adds a note about possible interactions between no_new_privs and LSMs (i.e. why teaching systemd to set no_new_privs is not necessarily a good idea), and it references the new docs from include/linux/prctl.h. Suggested-by: Rob Landley <[email protected]> Signed-off-by: Andy Lutomirski <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: James Morris <[email protected]>
aosmith · Jul 7, 2012 · c540521 · c540521
1 parent 26c439d
commit c540521
Show file tree

Hide file tree

Showing 2 changed files with 9 additions and 0 deletions.
diff --git a/Documentation/prctl/no_new_privs.txt b/Documentation/prctl/no_new_privs.txt
@@ -25,6 +25,13 @@ 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.

diff --git a/include/linux/prctl.h b/include/linux/prctl.h
@@ -141,6 +141,8 @@
  * Changing LSM security domain is considered a new privilege.  So, for example,
  * asking selinux for a specific new context (e.g. with runcon) will result
  * in execve returning -EPERM.
+ *
+ * See Documentation/prctl/no_new_privs.txt for more details.
  */
 #define PR_SET_NO_NEW_PRIVS	38
 #define PR_GET_NO_NEW_PRIVS	39