linux-kernel - Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces

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]

Message-ID: <CALCETrVTGC8NJdpOhkqDaE8HdD95y-K2-VnsL+Oo4NjVUyovsA@mail.gmail.com>
Date:	Wed, 15 Jul 2015 14:50:46 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Seth Forshee <seth.forshee@...onical.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	James Morris <james.l.morris@...cle.com>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>,
	SELinux-NSA <selinux@...ho.nsa.gov>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces

On Wed, Jul 15, 2015 at 2:48 PM, Serge E. Hallyn <serge@...lyn.com> wrote:
> On Wed, Jul 15, 2015 at 02:46:04PM -0500, Seth Forshee wrote:
>> Capability sets attached to files must be ignored except in the
>> user namespaces where the mounter is privileged, i.e. s_user_ns
>> and its descendants. Otherwise a vector exists for gaining
>> privileges in namespaces where a user is not already privileged.
>>
>> Add a new helper function, in_user_ns(), to test whether a user
>> namespace is the same as or a descendant of another namespace.
>> Use this helper to determine whether a file's capability set
>> should be applied to the caps constructed during exec.
>>
>> Signed-off-by: Seth Forshee <seth.forshee@...onical.com>
>
> Acked-by: Serge Hallyn <serge.hallyn@...onical.com>
>
> I think it's an ok behavior, though let's just go over the
> alternatives.
>
> It might actually be ok to simply require that the user_ns be
> equal.  If I unshare a new userns in which a different uid is
> mapped to root, I may not want file capabilities to be granted
> to tasks in that ns.  (On the other hand, I might be creating
> a new user_ns specifically to not have a uid 0 mapped into it
> at all, and only have file capabilities grant privilege)
>
> Conversely, if I unshare one user_ns with a MS_SHARED mnt_ns, mount
> an ext4fs, and then (from the parent shell) unshare another user_ns
> with the same mapping, intending it to be a "peer" to the first one
> I'd unshared and be able to use the ext4fs it mounted.  This won't
> work here.  That's probably best - the appropriate thing to do was
> to attach to the existing user_ns.  But it could end up being
> limiting in some special cases, so I'm bringing it up here.
>
> Again I think what you have here is the simplest and most sensible
> choice, so ack.
>

I think I'm missing something.  Why is this separate from mount_may_suid?

I can see why it would make sense to check s_user_ns (or maybe
s_user_ns *and* the vfsmount namespace) in mount_may_suid, but I don't
see why we need separate checks.

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