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: <87io9kzq5g.fsf@x220.int.ebiederm.org>
Date:	Wed, 15 Jul 2015 23:23:55 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Seth Forshee <seth.forshee@...onical.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\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces

Ok.  Andy I have stopped and really looked at your patch that is 4/7 in
this series.  Something I had not done before since it sounded totally
wrong.

That combined with your earlier comments I think I can say something
meaningful.  

Andy as I read your patch the thread you are primarily worried about is
chdir(/some/directory/in/another/mnt/ns).  I think enhancing nosuid to
deal with that case is reasonable, and is unlikely to break userspace.
It is one of those hairy security things so we need to be careful not to
introduce a regression.

I think a top down enhancement of nosuid to just block funny cases that
no one cares about is completely sensible.    Removing goofy corner
that no one cares about and that are only good for security exploits
seems reasonable.

I am a little concerned that smack does not seem to respect nosuid
on filesystems.  But that is an issue with nosuid not with your enhanced
nosuid.

Now this patch 3/7 really should be entitled:
"Limit file caps to the userns of the super block".

It really really is doing something different.   This change is about a
bottom up understanding of what file caps means on a filesystem mounted
by a user namespace root. 

That is file caps should only apply to the user namespace root of the
root user who mounted the filesystem, because that is all the privileges
the mounter of the filesystem had.

This guarantees that even if the filesystem somehow propagates with
mount propagation that there will be no issues.  I think I know how to
make that happen...

But deeply and fundamentally limiting a filesystem to only the
privilieges of it's user namespace root, and enhancing nosuid
protections are rather different things.

The approaches show up differently for dealing with uids and gids,
as mappings are required.  The approaches will likely to continue to
show up differently for file caps when Serge implements a version
of file caps with a user namespace root in them.

The approaches fundamentally will need to do different things with
security xattrs.  As mnt_may_suid can just treat as a filesystem
without labels, while ultimately the lsms will have to do something
meaningful.

So while in the very narrow case of todays file caps the two approaches
are the same.   Enhancing nosuid is something very different from
limiting a filesystem to it's mounters user namespace.

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