[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1439240719-46850-1-git-send-email-seth.forshee@canonical.com>
Date: Mon, 10 Aug 2015 16:05:11 -0500
From: Seth Forshee <seth.forshee@...onical.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-mtd@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov
Cc: Serge Hallyn <serge.hallyn@...onical.com>,
Andy Lutomirski <luto@...capital.net>,
linux-kernel@...r.kernel.org,
Seth Forshee <seth.forshee@...onical.com>,
John Johansen <john.johansen@...onical.com>,
Kentaro Takeda <takedakn@...data.co.jp>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
James Morris <james.l.morris@...cle.com>,
Kees Cook <keescook@...omium.org>
Subject: [PATCH v2 0/7] Initial support for user namespace owned mounts
This series adds support for the idea of superblocks owned by
unprivileged user namespaces. This is initially used to simplify the
MNT_NODEV handling for unpivileged mounts, and the ultimate goal is to
allow mounting of additional filesystem types from unprivileged
containers. As such these are the first in a larger set of patches, with
the full series (so far) available at:
git://kernel.ubuntu.com/sforshee/linux.git userns-mounts
The strategy for the series as a whole is to do as much of the heavy
lifting as possible in the vfs to avoid the need to handle any weird
edge cases in the code for individual filesystems. These patches lay the
initial groundwork and fall into a two broad groups:
1. Patches 1-2 add s_ser_ns and simplify MNT_NODEV handling.
2. Patches 3-7 tighten down security for mounts with s_user_ns !=
&init_user_ns. This includes updates to how file caps and suid are
handled and updates for SELinux and Smack to avoid using security
labels from untrusted mounts.
Note that no updates are included for the LSMs which do not store
security labels on disk. As far as I can tell these security modules are
not susceptible to attack via unprivileged mounts because no security
metadata can be injected into the system via these mounts. I have cc-ed
the maintainers of these LSMs and would appreciate confirmation that
this is the case.
Also note that this only addresses security at the vfs level. As has
been discussed previously, individual filesystems may still be
vulnerable to attacks via maliciuos metadata in the backing store. The
goal is to find a small set of filesystems that can be hardened against
attacks from below. At minimum fuse has been designed to resist such
attacks.
Changes since v1:
- Check current_user_ns instead of mount ns owner for MNT_LOCK_NODEV
check in fs_fully_visible.
- Add check of s_user_ns in mnt_may_suid.
- Improve handling of superblocks from unprivileged users in SELinux
and Smack.
- Add permission checks for block device paths passed to mount by
unprivileged users.
Andy Lutomirski (1):
fs: Treat foreign mounts as nosuid
Eric W. Biederman (1):
userns: Simpilify MNT_NODEV handling.
Seth Forshee (5):
fs: Add user namesapace member to struct super_block
fs: Verify access of user towards block device file when mounting
fs: Limit file caps to the user namespace of the super block
Smack: Add support for unprivileged mounts from user namespaces
selinux: Add support for unprivileged mounts from user namespaces
drivers/mtd/mtdsuper.c | 7 +++++-
fs/block_dev.c | 54 +++++++++++++++++++++++++++++++++---------
fs/exec.c | 2 +-
fs/namei.c | 9 ++++++-
fs/namespace.c | 34 +++++++++++++++-----------
fs/proc/root.c | 3 ++-
fs/super.c | 38 +++++++++++++++++++++++++----
include/linux/fs.h | 11 ++++++++-
include/linux/mount.h | 1 +
include/linux/user_namespace.h | 8 +++++++
kernel/user_namespace.c | 14 +++++++++++
security/commoncap.c | 4 +++-
security/selinux/hooks.c | 25 ++++++++++++++++++-
security/smack/smack.h | 6 +++++
security/smack/smack_lsm.c | 35 ++++++++++++++++++++-------
15 files changed, 206 insertions(+), 45 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists