Open Stack

On Fri, 2014-06-13 at 17:55 -0400, Eric Windisch wrote:
> >
> >
> > Why would you mount it from within the container?  CAP_SYS_ADMIN is a
> > per process property, so you use nsenter to execute the mount in the
> > required mount namespace with CAP_SYS_ADMIN from outside of the
> > container (i.e. the host).  I assume this requires changes to cinder so
> > it executes a mount rather than presenting a mountable device node, but
> > it's the same type of change we have to do for mounts which have no
> > node, like bind mounts.
> >
> 
> It's a matter of API adherence. You're right, however, another option for
> this etherpad is, "extend the API". We could add an extension to OpenStack
> that allows the host to initiate a mount inside an instance.  That isn't
> much different than the existing suggestion of a container-level API for
> speaking back to the host to initiate a mount, other than this suggestion
> being at the orchestration layer, rather than at the host-level.

OK, but this argument is effectively saying hypervisors can't do this,
so our API doesn't allow it ... it's true but a bit useless.  Containers
have all sorts of great capabilities that hypervisors don't.  The number
one great one from a security point of view is being able to reach into
the container from the host and do or configure things that the
container itself is prevented from doing.

This allows you to set up a completely secure babysat environment where
any dangerous action by the container gets referred up to the host to
perform.

> In part, this discussion and the exercise of writing this etherpad is to
> explore alternatives to "this isn't a valid use-case".  At a high-level,
> the alternatives seem to be to have an API the containers can use speak
> back to the host to initiate mounts or finding some configuration of the
> kernel (possibly with new features) that would provide a long-term solution.
> 
> I'm not fond of an API based solution because it means baking in
> expectations of a specific containers-service API such as the Docker API,
> or of a specific orchestration API such as the OpenStack Compute API. It
> might, however, be a good short-term option.

This is saying we (the container implementations) all do this in
different ways, which is true, but there's no reason we couldn't all
agree on a granular way of doing it we could then translate to an
OpenStack API ... we just need the action performed; I don't think any
of us has a great attachment to *how* the action is performed.  I think
the recently announced libcontainers effort will help us here because it
actually has a mount API ... we could 

> Daniel also brings up an interesting point about user namespaces, although
> I'm somewhat worried about that approach given that we can exploit the host
> with crafty filesystems. It had been considered that we could provide
> configurations that only allow FUSE. Granted, there might be some
> possibility of implementing a solution that would limit containers to
> mounting specific types of filesystems, such as only allowing FUSE mounts.

I replied in the other thread, but I think CAP_SYS_ADMIN is too
dangerous for a really secure container.

James