linux-kernel - Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in 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: <20140515040032.GA6702@kroah.com>
Date:	Wed, 14 May 2014 21:00:32 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"Michael H. Warfield" <mhw@...tsEnd.com>,
	linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
	Arnd Bergmann <arnd@...db.de>,
	Eric Biederman <ebiederm@...ssion.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	lxc-devel@...ts.linuxcontainers.org
Subject: Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user
 namespaces

On Wed, May 14, 2014 at 10:15:27PM -0500, Seth Forshee wrote:
> On Wed, May 14, 2014 at 10:17:31PM -0400, Michael H. Warfield wrote:
> > > > Using devtmpfs is one possible
> > > > solution, and it would have the added benefit of making container setup
> > > > simpler. But simply letting containers mount devtmpfs isn't sufficient
> > > > since the container may need to see a different, more limited set of
> > > > devices, and because different environments making modifications to
> > > > the filesystem could lead to conflicts.
> > > > 
> > > > This series solves these problems by assigning devices to user
> > > > namespaces. Each device has an "owner" namespace which specifies which
> > > > devtmpfs mount the device should appear in as well allowing priveleged
> > > > operations on the device from that namespace. This defaults to
> > > > init_user_ns. There's also an ns_global flag to indicate a device should
> > > > appear in all devtmpfs mounts.
> > 
> > > I'd strongly argue that this isn't even a "problem" at all.  And, as I
> > > said at the Plumbers conference last year, adding namespaces to devices
> > > isn't going to happen, sorry.  Please don't continue down this path.
> > 
> > I was just mentioning that to Serge just a week or so ago reminding him
> > of what you told all of us face to face back then.  We were having a
> > discussion over loop devices into containers and this topic came up.
> 
> It was the loop device use case that got me started down this path in
> the first place, so I don't personally have any interest in physical
> devices right now (though I was sure others would).

Why do you want to give access to a loop device to a container?
Shouldn't you set up the loop devices before creating the container and
then pass those mount points into the container?  I thought that was how
things worked today, or am I missing something?

Giving the ability for a container to create a loop device at all is a
horrid idea, as you have pointed out, lots of information leakage could
easily happen.

greg k-h
--
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/