From: ebiederm@xmission.com (Eric W. Biederman)
To: Andy Lutomirski <luto@amacapital.net>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Seth Forshee <seth.forshee@canonical.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Serge Hallyn <serge.hallyn@canonical.com>,
James Morris <james.l.morris@oracle.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
SELinux-NSA <selinux@tycho.nsa.gov>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces
Date: Wed, 15 Jul 2015 23:23:55 -0500 [thread overview]
Message-ID: <87io9kzq5g.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <CALCETrULyv9pfwAeyNrvJ06o+bW6JbWgBOsi4b4OUhbPjD4FnQ@mail.gmail.com> (Andy Lutomirski's message of "Wed, 15 Jul 2015 18:19:46 -0700")
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
next prev parent reply other threads:[~2015-07-16 4:30 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 19:46 [PATCH 0/7] Initial support for user namespace owned mounts Seth Forshee
2015-07-15 19:46 ` [PATCH 1/7] fs: Add user namesapace member to struct super_block Seth Forshee
2015-07-16 2:47 ` Eric W. Biederman
2015-08-05 21:03 ` Seth Forshee
2015-08-05 21:19 ` Eric W. Biederman
2015-08-06 14:20 ` Seth Forshee
2015-08-06 14:51 ` Stephen Smalley
2015-08-06 15:44 ` Seth Forshee
2015-08-06 16:11 ` Stephen Smalley
2015-08-07 14:16 ` Seth Forshee
2015-08-07 14:32 ` Seth Forshee
2015-08-07 18:35 ` Casey Schaufler
2015-08-07 18:57 ` Seth Forshee
2015-07-15 19:46 ` [PATCH 2/7] userns: Simpilify MNT_NODEV handling Seth Forshee
2015-07-15 19:46 ` [PATCH 3/7] fs: Ignore file caps in mounts from other user namespaces Seth Forshee
2015-07-15 21:48 ` Serge E. Hallyn
2015-07-15 21:50 ` Andy Lutomirski
2015-07-15 22:35 ` Eric W. Biederman
2015-07-16 1:14 ` Seth Forshee
2015-07-16 1:23 ` Andy Lutomirski
2015-07-16 13:06 ` Seth Forshee
2015-07-16 1:19 ` Andy Lutomirski
2015-07-16 4:23 ` Eric W. Biederman [this message]
2015-07-16 4:49 ` Andy Lutomirski
2015-07-16 5:04 ` Eric W. Biederman
2015-07-16 5:15 ` Andy Lutomirski
2015-07-16 5:44 ` Eric W. Biederman
2015-07-16 13:13 ` Seth Forshee
2015-07-17 0:43 ` Eric W. Biederman
2015-07-29 16:04 ` Serge E. Hallyn
2015-07-29 16:18 ` Serge E. Hallyn
2015-07-15 19:46 ` [PATCH 4/7] fs: Treat foreign mounts as nosuid Seth Forshee
2015-07-17 6:46 ` Nikolay Borisov
2015-07-15 19:46 ` [PATCH 5/7] security: Restrict security attribute updates for userns mounts Seth Forshee
2015-07-15 19:46 ` [PATCH 6/7] selinux: Ignore security labels on user namespace mounts Seth Forshee
2015-07-16 13:23 ` Stephen Smalley
2015-07-22 16:02 ` Stephen Smalley
2015-07-22 16:14 ` Seth Forshee
2015-07-22 20:25 ` Stephen Smalley
2015-07-22 20:40 ` Stephen Smalley
2015-07-23 13:57 ` Stephen Smalley
2015-07-23 14:39 ` Seth Forshee
2015-07-23 15:36 ` Stephen Smalley
2015-07-23 16:23 ` Seth Forshee
2015-07-24 15:11 ` Seth Forshee
2015-07-30 15:57 ` Stephen Smalley
2015-07-30 16:24 ` Seth Forshee
2015-07-15 19:46 ` [PATCH 7/7] smack: Don't use security labels for " Seth Forshee
2015-07-15 20:43 ` Casey Schaufler
2015-07-15 20:36 ` [PATCH 0/7] Initial support for user namespace owned mounts Casey Schaufler
2015-07-15 21:06 ` Eric W. Biederman
2015-07-15 21:48 ` Seth Forshee
2015-07-15 22:28 ` Eric W. Biederman
2015-07-16 1:05 ` Andy Lutomirski
2015-07-16 2:20 ` Eric W. Biederman
2015-07-16 13:12 ` Stephen Smalley
2015-07-15 23:04 ` Casey Schaufler
2015-07-15 22:39 ` Casey Schaufler
2015-07-16 1:08 ` Andy Lutomirski
2015-07-16 2:54 ` Casey Schaufler
2015-07-16 4:47 ` Eric W. Biederman
2015-07-17 0:09 ` Dave Chinner
2015-07-17 0:42 ` Eric W. Biederman
2015-07-17 2:47 ` Dave Chinner
2015-07-21 17:37 ` J. Bruce Fields
2015-07-22 7:56 ` Dave Chinner
2015-07-22 14:09 ` J. Bruce Fields
2015-07-22 16:52 ` Austin S Hemmelgarn
2015-07-22 17:41 ` J. Bruce Fields
2015-07-23 1:51 ` Dave Chinner
2015-07-23 13:19 ` J. Bruce Fields
2015-07-23 23:48 ` Dave Chinner
2015-07-18 0:07 ` Serge E. Hallyn
2015-07-20 17:54 ` Colin Walters
2015-07-16 11:16 ` Lukasz Pawelczyk
2015-07-17 0:10 ` Eric W. Biederman
2015-07-17 10:13 ` Lukasz Pawelczyk
2015-07-16 3:15 ` Eric W. Biederman
2015-07-16 13:59 ` Seth Forshee
2015-07-16 15:09 ` Casey Schaufler
2015-07-16 18:57 ` Seth Forshee
2015-07-16 21:42 ` Casey Schaufler
2015-07-16 22:27 ` Andy Lutomirski
2015-07-16 23:08 ` Casey Schaufler
2015-07-16 23:29 ` Andy Lutomirski
2015-07-17 0:45 ` Casey Schaufler
2015-07-17 0:59 ` Andy Lutomirski
2015-07-17 14:28 ` Serge E. Hallyn
2015-07-17 14:56 ` Seth Forshee
2015-07-21 20:35 ` Seth Forshee
2015-07-22 1:52 ` Casey Schaufler
2015-07-22 15:56 ` Seth Forshee
2015-07-22 18:10 ` Casey Schaufler
2015-07-22 19:32 ` Seth Forshee
2015-07-23 0:05 ` Casey Schaufler
2015-07-23 0:15 ` Eric W. Biederman
2015-07-23 5:15 ` Seth Forshee
2015-07-23 21:48 ` Casey Schaufler
2015-07-28 20:40 ` Seth Forshee
2015-07-30 16:18 ` Casey Schaufler
2015-07-30 17:05 ` Eric W. Biederman
2015-07-30 17:25 ` Seth Forshee
2015-07-30 17:33 ` Eric W. Biederman
2015-07-17 13:21 ` Seth Forshee
2015-07-17 17:14 ` Casey Schaufler
2015-07-16 15:59 ` Seth Forshee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87io9kzq5g.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=james.l.morris@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=selinux@tycho.nsa.gov \
--cc=serge.hallyn@canonical.com \
--cc=serge@hallyn.com \
--cc=seth.forshee@canonical.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®