linux-kernel - Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device

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: <1401158362.7572.138.camel@canyon.ip6.wittsend.com>
Date:	Mon, 26 May 2014 22:39:22 -0400
From:	"Michael H. Warfield" <mhw@...tsEnd.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	"Michael H.Warfield" <mhw@...tsEnd.com>,
	LXC development mailing-list 
	<lxc-devel@...ts.linuxcontainers.org>, Marian Marinov <mm@...com>,
	Jens Axboe <axboe@...nel.dk>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [lxc-devel] [RFC PATCH 11/11] loop: Allow priveleged operations
 for root in the namespace which owns a device

On Tue, 2014-05-27 at 03:36 +0200, Serge E. Hallyn wrote:
> Quoting Michael H. Warfield (mhw@...tsEnd.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.  How that translates into what is and
is not visible and what can be mimiced in a container becomes important
(to say nothing of notifying its udev).  I think this loopfs thing is
the answer for the loop device case, we just need to clear up those
details and exorcise the devils we find in them.  The loop devices are
unique while they strangely seem to work with minimal leakage already
(all meta data at this time).

Seth remarked that, maybe, he's not paranoid enough.  You know that I'm
a well trained professional paranoid and I accept if people think I'm
overly paranoid (is that even possible?).  Even paranoids have enemies
and just because you're paranoid it doesn't mean they're not out to get
you.  While I admit that total isolation is virtually (excuse the pun)
impossible that doesn't mean I don't strive to maximize the isolation
and analyze the possibilities and consequences of compromise.

As I stated, "I don't see any way to avoid it".  I would love to be
proven wrong.  It would permit my life to be so much more easy.  But how
can we allow this without the host in control of it and directing things
to the containers?  A container may request something and the host can
grant it but the container should not be capable of demanding a device
over and above the control of the host.  How do we define the rules that
say what a container can do and what it cannot do without it involving
knowledge in the host (whitelisting as Seth call's it) of what is and is
not allowed in the container?

We already have the problem that the container devices.allow and
devices.deny are major and minor based, which we know is fundamentally
flawed in a udev environment.  We specify major:minor in the
configuration files as if they are cast in cement (which they are in all
common cases) but they are not in the general case.  Greg K-H hammers on
this frequently.

The loop devices are unique and deserve a unique solution, I'll agree.
But I'm also comfortable that the host should have rules and procedures
to whitelist hard devices and loop devices and manage their transfer
and/or sharing into the containers.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw@...tsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

Download attachment "signature.asc" of type "application/pgp-signature" (483 bytes)