security: Minor improvements to no_new_privs documentation
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 56ad7562a2a40a29b8ce72f4ec5e5836c5cb72f6.1341512511.git.luto@amacapital.net
Please pull for 3.5.
The following changes since commit 26c439d4005d94b8da28e023e285fd4a9943470e:
Linus Torvalds (1):
Merge tag 'ecryptfs-3.5-rc6-fixes' of git://git.kernel.org/.../tyhicks/ecryptfs
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus
Andy Lutomirski (1):
security: Minor improvements to no_new_privs documentation
Documentation/prctl/no_new_privs.txt | 7 +++++++ include/linux/prctl.h | 2 ++ 2 files changed, 9 insertions(+)
commit c540521bba5d2f24bd2c0417157bfaf8b85e2eee
Author: Andy Lutomirski <[email protected]> Date: Thu Jul 5 11:23:24 2012 -0700
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.
Documentation/prctl/no_new_privs.txt +7 -0
@@ -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
@@ -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