Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

[Serge Hallyn]

Quoting Michael H. Warfield (mhw@xxxxxxxxxxxx):
> On Mon, 2014-05-19 at 17:04 -0700, Eric W. Biederman wrote:
> > Seth Forshee <seth.forshee@xxxxxxxxxxxxx> 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

Yes so in this case by more privileged' he meant a privileged user in a
userns which is ancestor to the current userns.  It is in fact *more*
privileged than any user in the current userns.

> heiarchial.  If someone has that "priv" then they have access.  If they

They are in fact implicitly hierarchical due to the hierarchical userns
design.

> 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@xxxxxxxxxxxx
>    /\/\|=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!
> 



> _______________________________________________
> lxc-devel mailing list
> lxc-devel@xxxxxxxxxxxxxxxxxxxxxxxxx
> http://lists.linuxcontainers.org/listinfo/lxc-devel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/