linux-kernel - Re: [PATCH 0/7] Initial support for user namespace owned mounts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 15 Jul 2015 18:05:52 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	SELinux-NSA <selinux@...ho.nsa.gov>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Seth Forshee <seth.forshee@...onical.com>
Subject: Re: [PATCH 0/7] Initial support for user namespace owned mounts

On Jul 15, 2015 3:34 PM, "Eric W. Biederman" <ebiederm@...ssion.com> wrote:
>
> Seth Forshee <seth.forshee@...onical.com> writes:
>
> > On Wed, Jul 15, 2015 at 04:06:35PM -0500, Eric W. Biederman wrote:
> >> Casey Schaufler <casey@...aufler-ca.com> writes:
> >>
> >> > On 7/15/2015 12:46 PM, Seth Forshee wrote:
> >> >> These are the first in a larger set of patches that I've been working on
> >> >> (with help from Eric Biederman) to support mounting ext4 and fuse
> >> >> filesystems from within user namespaces. I've pushed the full series to:
> >> >>
> >> >>   git://kernel.ubuntu.com/sforshee/linux.git userns-mounts
> >> >>
> >> >> Taking the series as a whole, the strategy is to handle as much of the
> >> >> heavy lifting as possible in the vfs so the filesystems don't have to
> >> >> handle weird edge cases. If you look at the full series you'll find that
> >> >> the changes in ext4 to support user namespace mounts turn out to be
> >> >> fairly minimal (fuse is a bit more complicated though as it must deal
> >> >> with translating ids for a userspace process which is running in pid and
> >> >> user namespaces).
> >> >>
> >> >> The patches I'm sending today lay some of the groundwork in the vfs and
> >> >> related code. They fall into two broad groups:
> >> >>
> >> >>  1. Patches 1-2 add s_user_ns and simplify MNT_NODEV handling. These are
> >> >>     pretty straightforward, and Eric has expressed interest in merging
> >> >>     these patches soon. Note that patch 2 won't apply cleanly without
> >> >>     Eric's noexec patches for proc and sys [1].
> >> >>
> >> >>  2. Patches 2-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 LSM updates to ignore security labels on superblocks
> >> >>     from non-init namespaces.
> >> >>
> >> >>     The LSM changes in particular may not be optimal, as I don't have a
> >> >>     lot of familiarity with this code, so I'd be especially appreciative
> >> >>     of review of these changes and suggestions on how to improve them.
> >> >
> >> > Lukasz Pawelczyk <l.pawelczyk@...sung.com> proposed
> >> > LSM support in user namespaces ([RFC] lsm: namespace hooks)
> >> > that make a whole lot more sense than just turning off
> >> > the option of using labels on files. Gutting the ability
> >> > to use MAC in a namespace is a step down the road of
> >> > making MAC and namespaces incompatible.
> >>
> >> This is not "turning off the option to use labels on files".
> >>
> >> This is supporting mounting filesystems like ext4 by unprivileged users
> >> and not trusting the labels they set in the same way as we trust labels
> >> on filesystems mounted by privileged users.
> >>
> >> The first step needs to be not trusting those labels and treating such
> >> filesystems as filesystems without label support.  I hope that is Seth
> >> has implemented.
> >>
> >> In the long run we can do more interesting things with such filesystems
> >> once the appropriate LSM policy is in place.
> >
> > Yes, this exactly. Right now it looks to me like the only safe thing to
> > do with mounts from unprivileged users is to ignore the security labels,
> > so that's what I'm trying to do with these changes. If there's some
> > better thing to do, or some better way to do it, I'm more than happy to
> > receive that feedback.
>
> Ugh.
>
> This made me realize that we have an interesting problem here.  An
> unprivileged mount of tmpfs probably needs to have
> s_user_ns == &init_user_ns.
>
> Otherwise we will break security labels on tmpfs for no good reason.
> ramfs and sysfs also seem to have similar concerns.
>
> Because they have no backing store we can trust those filesystems with
> security labels.  Plus for at least sysfs there is the security label
> bleed through issue, that we need to make certain works.
>
> Perhaps these filesystems with trusted backing store need to call
> "sget_userns(..., &init_user_ns)".
>
> If we don't get this right we will have significant regressions with
> respect to security labels, and that is not ok.

That's only a problem if there's anyone who sets security labels on
such a mount.  You need global caps to do that (I hope), which
requires someone outside the userns to help, which means there's a
good chance that literally no one does this.

--Andy
--
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/