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]
Message-ID: <20140527013634.GA3524@mail.hallyn.com>
Date:	Tue, 27 May 2014 03:36:34 +0200
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Michael H. Warfield" <mhw@...tsEnd.com>
Cc:	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

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.  
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ