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
Unified · Split
| @@ -25,6 +25,13 @@ bits will no longer change the uid or gid; file capabilities will not · 24 unmodified lines | ||
| 25 | 25 | add to the permitted set, and LSMs will not relax constraints after |
| 26 | 26 | execve. |
| 27 | 27 | |
| 28 | +To set no_new_privs, use prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0). | |
| 29 | + | |
| 30 | +Be careful, though: LSMs might also not tighten constraints on exec | |
| 31 | +in no_new_privs mode. (This means that setting up a general-purpose | |
| 32 | +service launcher to set no_new_privs before execing daemons may | |
| 33 | +interfere with LSM-based sandboxing.) | |
| 34 | + | |
| 28 | 35 | Note that no_new_privs does not prevent privilege changes that do not |
| 29 | 36 | involve execve. An appropriately privileged task can still call |
| 30 | 37 | setuid(2) and receive SCM_RIGHTS datagrams. |
| @@ -141,6 +141,8 @@ · 140 unmodified lines | ||
| 141 | 141 | * Changing LSM security domain is considered a new privilege. So, for example, |
| 142 | 142 | * asking selinux for a specific new context (e.g. with runcon) will result |
| 143 | 143 | * in execve returning -EPERM. |
| 144 | + * | |
| 145 | + * See Documentation/prctl/no_new_privs.txt for more details. | |
| 144 | 146 | */ |
| 145 | 147 | #define PR_SET_NO_NEW_PRIVS 38 |
| 146 | 148 | #define PR_GET_NO_NEW_PRIVS 39 |