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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 May 2014 21:14:41 -0400
From:	"Michael H. Warfield" <mhw@...tsEnd.com>
To:	LXC development mailing-list <lxc-devel@...ts.linuxcontainers.org>
Cc:	"Michael H.Warfield" <mhw@...tsEnd.com>,
	Seth Forshee <seth.forshee@...onical.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,
	James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user
 namespaces

On Mon, 2014-05-19 at 17:04 -0700, Eric W. Biederman wrote:
> Seth Forshee <seth.forshee@...onical.com> writes:
> 
> > What I set out for was feature parity between loop devices in a secure
> > container and loop devices on the host. Since some operations currently
> > check for system-wide CAP_SYS_ADMIN, the only way I see to accomplish
> > this is to push knowledge of the user namespace farther down into the
> > driver stack so the check can instead be for CAP_SYS_ADMIN in the user
> > namespace associated with the device.
> >
> > That said, I suspect our current use cases can get by without these
> > capabilities. Really though I suspect this is just deferring the
> > discussion rather than settling it, and what we'll end up with is little
> > more than a fancy way for userspace to ask the kernel to run mknod on
> > its behalf.

> A fancy way to ask the kernel to run mknod on its behalf is what
> /dev/pts is.

> When I suggested this I did not mean you should forgo making changes to
> allow partitions and the like.  What I itended is that you should find a
> way to make this safe for users who don't have root capabilities.

I like to think in terms of the "rootless" configurations where "root"
per se is not absolute and everything is framed in terms of
capabilities.

> Which possibly means that mount needs to learn how to keep a more
> privileged user from using your new loop devices.

Not sure I got that one.  As user with "more" privileges may or may not
have access dependent on the congruence of the privileges.  They're not
heiarchial.  If someone has that "priv" then they have access.  If they
do not, they do not.

> To get to the point where this is really and truly usable I expect to be
> technically daunting.

Most technically non-trivial problems generally are.

> Ultimately the technical challenge is how do we create a block device
> that is safe for a user who does not have any capabilities to use, and
> what can we do with that block device to make it useful.

Concur.  It boils down to privilege management and access.  Absolutely
concur.

> Only when the question is can this kernel functionality which is
> otherwise safe confuse a preexisting setuid application do namespace
> or container bits significantly come into play.

Ah...  Admittedly it's not as late as our conversation at LinuxPlumbers
last year in NOLA but...  Maybe late at night but I failed to parse the
above.

> Eric

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)