Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
Pull security docs update from James Morris. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: security: Minor improvements to no_new_privs documentation
This commit is contained in:
commit
a0127afbed
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue