From: "Theodore Ts'o" <tytso@mit.edu>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>,
Marian Marinov <mm@1h.com>,
containers@lists.linux-foundation.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
lxc-devel <lxc-devel@lists.sourceforge.net>
Subject: Re: ioctl CAP_LINUX_IMMUTABLE is checked in the wrong namespace
Date: Tue, 29 Apr 2014 19:06:24 -0400 [thread overview]
Message-ID: <20140429230624.GA28966@thunk.org> (raw)
In-Reply-To: <53602B84.1020304@mit.edu>
On Tue, Apr 29, 2014 at 03:45:24PM -0700, Andy Lutomirski wrote:
>
> Wait, what?
>
> Inodes aren't owned by user namespaces; they're owned by users. And any
> user can arrange to have a user namespace in which they pass an
> inode_capable check on any inode that they own.
>
> Presumably there's a reason that CAP_SYS_IMMUTABLE is needed. If this
> gets merged, then it would be better to just drop CAP_SYS_IMMUTABLE
> entirely.
>
> Nacked-by: Andy Lutomirski <luto@amacapital.net>
Right, but you can't set a mapping in a child namespace unless you
have CAP_SETUID in the parent namespace, right? Otherwise user
namespaces are completely broken from a security perspective, since
inode_capable() could never do the right thing.
Personally, reading how user namespaces work, it makes the hair rise
on the back of my neck. I'm not sure the concept works at all from a
security perspective, but hey, I'm not using user namespaces, and some
fool thought it was worth merging. :-)
- Ted
next prev parent reply other threads:[~2014-04-29 23:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 13:49 ioctl CAP_LINUX_IMMUTABLE is checked in the wrong namespace Marian Marinov
2014-04-29 18:35 ` Theodore Ts'o
2014-04-29 18:52 ` Serge Hallyn
2014-04-29 21:49 ` Marian Marinov
2014-04-29 22:02 ` Serge Hallyn
2014-04-29 22:24 ` Marian Marinov
2014-04-29 22:29 ` Serge Hallyn
2014-04-29 22:45 ` Andy Lutomirski
2014-04-29 23:06 ` Theodore Ts'o [this message]
2014-04-29 23:07 ` Andy Lutomirski
2014-04-29 23:20 ` Marian Marinov
2014-04-29 23:22 ` Andy Lutomirski
2014-04-29 23:47 ` Stéphane Graber
2014-04-29 23:51 ` Andy Lutomirski
2014-04-30 0:01 ` Stéphane Graber
2014-04-30 0:10 ` Marian Marinov
2014-04-30 0:12 ` Andy Lutomirski
2014-04-30 0:11 ` Andy Lutomirski
2014-04-30 0:21 ` Serge Hallyn
2014-04-30 0:23 ` Andy Lutomirski
2014-04-30 0:44 ` Serge Hallyn
2014-04-30 1:03 ` Andy Lutomirski
2014-04-30 0:16 ` Serge Hallyn
2014-04-30 0:32 ` Theodore Ts'o
2014-04-30 0:33 ` Andy Lutomirski
2014-04-30 0:40 ` Serge Hallyn
2014-04-30 7:48 ` Eric W. Biederman
2014-04-30 13:33 ` Serge Hallyn
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=20140429230624.GA28966@thunk.org \
--to=tytso@mit.edu \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=lxc-devel@lists.sourceforge.net \
--cc=mm@1h.com \
--cc=serge.hallyn@ubuntu.com \
/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