]> git.proxmox.com Git - mirror_ubuntu-zesty-kernel.git/commit
UBUNTU: SAUCE: (namespace) capabilities: Allow privileged user in s_user_ns to set...
authorSeth Forshee <seth.forshee@canonical.com>
Tue, 26 Apr 2016 19:36:30 +0000 (14:36 -0500)
committerTim Gardner <tim.gardner@canonical.com>
Mon, 20 Feb 2017 03:57:58 +0000 (20:57 -0700)
commit7f4a3d09419ea2b34df92e4ebbd9f02a44450d7f
tree95e317d2abab7af7543fec0992c66e335844f7d3
parentf17a309193c6b25d84d15685a0eef124d8cecf1f
UBUNTU: SAUCE: (namespace) capabilities: Allow privileged user in s_user_ns to set security.* xattrs

A privileged user in s_user_ns will generally have the ability to
manipulate the backing store and insert security.* xattrs into
the filesystem directly. Therefore the kernel must be prepared to
handle these xattrs from unprivileged mounts, and it makes little
sense for commoncap to prevent writing these xattrs to the
filesystem. The capability and LSM code have already been updated
to appropriately handle xattrs from unprivileged mounts, so it
is safe to loosen this restriction on setting xattrs.

The exception to this logic is that writing xattrs to a mounted
filesystem may also cause the LSM inode_post_setxattr or
inode_setsecurity callbacks to be invoked. SELinux will deny the
xattr update by virtue of applying mountpoint labeling to
unprivileged userns mounts, and Smack will deny the writes for
any user without global CAP_MAC_ADMIN, so loosening the
capability check in commoncap is safe in this respect as well.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
security/commoncap.c