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

Commit c540521b authored by Andy Lutomirski's avatar Andy Lutomirski Committed by James Morris
Browse files

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: default avatarRob Landley <rob@landley.net>
Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
Acked-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
parent 26c439d4

Documentation/prctl/no_new_privs.txt

+7 −0
Original line number Original line 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

add to the permitted set, and LSMs will not relax constraints after

execve.

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

Note that no_new_privs does not prevent privilege changes that do not

involve execve.  An appropriately privileged task can still call

involve execve.  An appropriately privileged task can still call

setuid(2) and receive SCM_RIGHTS datagrams.

setuid(2) and receive SCM_RIGHTS datagrams.

include/linux/prctl.h

+2 −0
Original line number Original line Diff line number Diff line
@@ -141,6 +141,8 @@ 
 * Changing LSM security domain is considered a new privilege.  So, for example,

 * 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

 * asking selinux for a specific new context (e.g. with runcon) will result

 * in execve returning -EPERM.

 * in execve returning -EPERM.

 *

 * See Documentation/prctl/no_new_privs.txt for more details.

 */

 */

#define PR_SET_NO_NEW_PRIVS	38

#define PR_SET_NO_NEW_PRIVS	38

#define PR_GET_NO_NEW_PRIVS	39

#define PR_GET_NO_NEW_PRIVS	39