Merge branch 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
Pull security layer fixes from James Morris. A documentation update, and a nommu build fix. * 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: security: Fix nommu build. security: document no_new_privs
This commit is contained in:
commit
3bfd245476
2 changed files with 51 additions and 0 deletions
50
Documentation/prctl/no_new_privs.txt
Normal file
50
Documentation/prctl/no_new_privs.txt
Normal file
|
@ -0,0 +1,50 @@
|
||||||
|
The execve system call can grant a newly-started program privileges that
|
||||||
|
its parent did not have. The most obvious examples are setuid/setgid
|
||||||
|
programs and file capabilities. To prevent the parent program from
|
||||||
|
gaining these privileges as well, the kernel and user code must be
|
||||||
|
careful to prevent the parent from doing anything that could subvert the
|
||||||
|
child. For example:
|
||||||
|
|
||||||
|
- The dynamic loader handles LD_* environment variables differently if
|
||||||
|
a program is setuid.
|
||||||
|
|
||||||
|
- chroot is disallowed to unprivileged processes, since it would allow
|
||||||
|
/etc/passwd to be replaced from the point of view of a process that
|
||||||
|
inherited chroot.
|
||||||
|
|
||||||
|
- The exec code has special handling for ptrace.
|
||||||
|
|
||||||
|
These are all ad-hoc fixes. The no_new_privs bit (since Linux 3.5) is a
|
||||||
|
new, generic mechanism to make it safe for a process to modify its
|
||||||
|
execution environment in a manner that persists across execve. Any task
|
||||||
|
can set no_new_privs. Once the bit is set, it is inherited across fork,
|
||||||
|
clone, and execve and cannot be unset. With no_new_privs set, execve
|
||||||
|
promises not to grant the privilege to do anything that could not have
|
||||||
|
been done without the execve call. For example, the setuid and setgid
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
There are two main use cases for no_new_privs so far:
|
||||||
|
|
||||||
|
- Filters installed for the seccomp mode 2 sandbox persist across
|
||||||
|
execve and can change the behavior of newly-executed programs.
|
||||||
|
Unprivileged users are therefore only allowed to install such filters
|
||||||
|
if no_new_privs is set.
|
||||||
|
|
||||||
|
- By itself, no_new_privs can be used to reduce the attack surface
|
||||||
|
available to an unprivileged user. If everything running with a
|
||||||
|
given uid has no_new_privs set, then that uid will be unable to
|
||||||
|
escalate its privileges by directly attacking setuid, setgid, and
|
||||||
|
fcap-using binaries; it will need to compromise something without the
|
||||||
|
no_new_privs bit set first.
|
||||||
|
|
||||||
|
In the future, other potentially dangerous kernel features could become
|
||||||
|
available to unprivileged tasks if no_new_privs is set. In principle,
|
||||||
|
several options to unshare(2) and clone(2) would be safe when
|
||||||
|
no_new_privs is set, and no_new_privs + chroot is considerable less
|
||||||
|
dangerous than chroot by itself.
|
|
@ -23,6 +23,7 @@
|
||||||
#include <linux/mman.h>
|
#include <linux/mman.h>
|
||||||
#include <linux/mount.h>
|
#include <linux/mount.h>
|
||||||
#include <linux/personality.h>
|
#include <linux/personality.h>
|
||||||
|
#include <linux/backing-dev.h>
|
||||||
#include <net/flow.h>
|
#include <net/flow.h>
|
||||||
|
|
||||||
#define MAX_LSM_EVM_XATTR 2
|
#define MAX_LSM_EVM_XATTR 2
|
||||||
|
|
Loading…
Reference in a new issue