Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit c540521b authored Jul 05, 2012 by Andy Lutomirski Committed by James Morris Jul 08, 2012

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 <rob@landley.net>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <james.l.morris@oracle.com>

parent 26c439d4

Documentation/prctl/no_new_privs.txt

+7 −0

Original line number	Diff line number	Diff line
		@@ -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.

include/linux/prctl.h

+2 −0

Original line number	Diff line number	Diff line
		@@ -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