From: Serge Hallyn <serge.hallyn@ubuntu.com>
To: "Michael H. Warfield" <mhw@WittsEnd.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
LXC development mailing-list
<lxc-devel@lists.linuxcontainers.org>, Marian Marinov <mm@1h.com>,
Jens Axboe <axboe@kernel.dk>,
Serge Hallyn <serge.hallyn@canonical.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device
Date: Tue, 27 May 2014 13:16:57 +0000 [thread overview]
Message-ID: <20140527131657.GK4232@ubuntumail> (raw)
In-Reply-To: <1401158362.7572.138.camel@canyon.ip6.wittsend.com>
Quoting Michael H. Warfield (mhw@WittsEnd.com):
> On Tue, 2014-05-27 at 03:36 +0200, Serge E. Hallyn wrote:
> > Quoting Michael H. Warfield (mhw@WittsEnd.com):
> > > On Mon, 2014-05-26 at 11:16 +0200, Seth Forshee wrote:
> > > > On Fri, May 23, 2014 at 08:48:25AM +0300, Marian Marinov wrote:
> > > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > > Hash: SHA1
> > > > >
> > > > > One question about this patch.
> > > > >
> > > > > Why don't you use the devices cgroup check if the root user in that namespace is allowed to use this device?
> > > > >
> > > > > This way you can be sure that the root in that namespace can not access devices to which the host system did not gave
> > > > > him access to.
> > >
> > > > That might be possible, but I don't want to require something on the
> > > > host to whitelist the device for the container. Then loop would need to
> > > > automatically add the device to devices.allow, which doesn't seem
> > > > desirable to me. But I'm not entirely opposed to the idea if others
> > > > think this is a better way to go.
> > >
> > > I don't see any safe way to avoid it. The host has to be in control of
> > > what devices can and can not be accessed by the container.
>
> > Disagree. loop%d is meaningless until it is attached to a file. So
> > whether a container can use loop2 vs loop9 is meaningless. The point
> > of Seth's loopfs as I understood it is that the container simply gets a
> > unique (not visible to host or any other containers) set of loop devices
> > which it can attach to files which it owns. So long as the host can't
> > see the container's loop devices (i.e. so it unwittently mounts it when
> > looking for a particular UUID for /var), it won't get fooled by them.
>
> > So in this case *if* we can do it, a purely namespaced approach - meaning
> > that we restrict visibility of a particular loopdev to one container - is
> > perfect.
>
> And in that "*if" is a cloud that says "then a miracle occurs" and that
> miracle needs a lot more detail.
Naturally. Which is why as Seth says we'll need concrete code to discuss.
But the concept that a well implemented namespace which prevents addressing
a given resource in the first place would suffice is, I think, a well
accepted premise of security in linux. And in this case it is more
appropriate than trying to finagle it into the devices cgroup. Note that
Marian said "to check if root user in that namespace is allowed to use
this device." This first off does not address the concern of root on the
host being tricked by the contents of loop0 which happens to be legitimately
used by container N. In contrast, making it so that loop0 is only
addressable by container N, and not by the host, does.
Anyway I as reading the above as why don't we *base* the containerized loop
on devices cgroups. I object to that. Well, at least until we rule out
more elegant solutions. Of course I don't object to defense in depth.
-serge
next prev parent reply other threads:[~2014-05-27 13:17 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 21:34 [RFC PATCH 00/11] Add support for devtmpfs in user namespaces Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 01/11] driver core: Assign owning user namespace to devices Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 02/11] driver core: Add device_create_global() Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 03/11] tmpfs: Add sub-filesystem data pointer to shmem_sb_info Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 04/11] ramfs: Add sub-filesystem data pointer to ram_fs_info Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 05/11] devtmpfs: Add support for mounting in user namespaces Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 06/11] drivers/char/mem.c: Make null/zero/full/random/urandom available to " Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 07/11] block: Make partitions inherit namespace from whole disk device Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 08/11] block: Allow blkdev ioctls within user namespaces Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 09/11] misc: Make loop-control available to all " Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 10/11] loop: Assign devices to current_user_ns() Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device Seth Forshee
2014-05-23 5:48 ` Marian Marinov
2014-05-26 9:16 ` Seth Forshee
2014-05-26 15:32 ` [lxc-devel] " Michael H. Warfield
2014-05-26 15:45 ` Seth Forshee
2014-05-27 1:36 ` Serge E. Hallyn
2014-05-27 2:39 ` Michael H. Warfield
2014-05-27 7:16 ` Seth Forshee
2014-05-27 13:16 ` Serge Hallyn [this message]
2014-05-15 1:32 ` [RFC PATCH 00/11] Add support for devtmpfs in user namespaces Greg Kroah-Hartman
2014-05-15 2:17 ` [lxc-devel] " Michael H. Warfield
2014-05-15 3:15 ` Seth Forshee
2014-05-15 4:00 ` Greg Kroah-Hartman
2014-05-15 13:42 ` Michael H. Warfield
2014-05-15 14:08 ` Greg Kroah-Hartman
2014-05-15 17:42 ` Serge Hallyn
2014-05-15 18:12 ` Seth Forshee
2014-05-15 22:15 ` Greg Kroah-Hartman
2014-05-16 1:42 ` Michael H. Warfield
2014-05-16 7:56 ` Richard Weinberger
2014-05-16 19:20 ` James Bottomley
2014-05-16 19:42 ` Michael H. Warfield
2014-05-16 19:52 ` [lxc-devel] Mount and other notifiers, was: " James Bottomley
2014-05-16 20:04 ` Michael H. Warfield
2014-05-16 1:49 ` [lxc-devel] " Serge Hallyn
2014-05-16 4:35 ` Greg Kroah-Hartman
2014-05-16 14:06 ` Seth Forshee
2014-05-16 15:28 ` Michael H. Warfield
2014-05-16 15:43 ` Seth Forshee
2014-05-16 18:57 ` Greg Kroah-Hartman
2014-05-16 19:28 ` James Bottomley
2014-05-16 20:18 ` Seth Forshee
2014-05-20 0:04 ` Eric W. Biederman
2014-05-20 1:14 ` Michael H. Warfield
2014-05-20 14:18 ` Serge Hallyn
2014-05-20 14:21 ` Seth Forshee
2014-05-21 22:00 ` Eric W. Biederman
2014-05-21 22:33 ` Serge Hallyn
2014-05-23 22:23 ` Eric W. Biederman
2014-05-28 9:26 ` Seth Forshee
2014-05-28 13:12 ` Serge E. Hallyn
2014-05-28 20:33 ` Eric W. Biederman
2014-05-18 2:42 ` Serge E. Hallyn
2014-05-17 4:31 ` Eric W. Biederman
2014-05-17 16:01 ` Seth Forshee
2014-05-18 2:44 ` Serge E. Hallyn
2014-05-19 13:27 ` Seth Forshee
2014-05-20 14:15 ` Serge Hallyn
2014-05-20 14:26 ` Serge Hallyn
2014-05-17 12:57 ` Michael H. Warfield
2014-05-15 18:25 ` Richard Weinberger
2014-05-15 19:50 ` Serge Hallyn
2014-05-15 20:13 ` Richard Weinberger
2014-05-15 20:26 ` Serge E. Hallyn
2014-05-15 20:33 ` Richard Weinberger
2014-05-19 20:22 ` Andy Lutomirski
2014-05-20 14:19 ` Serge Hallyn
2014-05-23 8:20 ` Marian Marinov
2014-05-23 13:16 ` James Bottomley
2014-05-23 16:39 ` Andy Lutomirski
2014-05-24 22:25 ` Serge Hallyn
2014-05-25 8:12 ` James Bottomley
2014-05-25 22:24 ` Serge E. Hallyn
2014-05-28 7:02 ` James Bottomley
2014-05-28 13:49 ` 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=20140527131657.GK4232@ubuntumail \
--to=serge.hallyn@ubuntu.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lxc-devel@lists.linuxcontainers.org \
--cc=mhw@WittsEnd.com \
--cc=mm@1h.com \
--cc=serge.hallyn@canonical.com \
--cc=serge@hallyn.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;
as well as URLs for NNTP newsgroup(s).