[lxc-devel] [PATCH] Use container specific domain socket name

[Serge Hallyn]

Well if we really want to go that route, we can

 a. specify a monitor-port in $lxcpath/lxc.conf
 b. write a world-unreadable $lxcpath/monitor-secret file
 c. require catting $lxcpath/monitor-secret at initial connection

so /var/lib/lxc/lxc.conf can have monitor-port=9998, while
/home/serge/lxcbase/lxc.conf has 9999, and
/var/lib/lxc/monitor-secret has uber-secure password 'god' while
/home/serge/lxcbase/monitor-secret contains 'mortal'.  Now user
serge can monitor his own containers on port 9999, but can't
listen on port 9998.  Of course we can still use a port < 1024
for root-owned containers for a bit more peace of mind.

But what I don't like about this is that it requires more setup, whereas
the AF_UNIX based solution requires no hand-cranking.

I suppose we could make monitor-port, if unspecified, default to
some-hash($lxcpath), and just say that the secret doesnt' have to
be specified (I'm not sure everyone will care about container
event spoofing).

-serge

Quoting S.Çağlar Onur (caglar at 10ur.org):
> Hi Serge,
> 
> Yeah you are correct we need regular users to be able to monitor their own
> containes. I guess we can encrypt the messages but I'm not going there :)
> 
> Cheers,
> 
> 
> On Wed, Apr 17, 2013 at 8:52 AM, Serge Hallyn <serge.hallyn at ubuntu.com>wrote:
> 
> > Quoting S.Çağlar Onur (caglar at 10ur.org):
> > > Hi there,
> > >
> > > What about using AF_INET but binding a restricted port while adding a new
> > > field to the message? As an example we can start to create a hmac (or
> > > something like that) per container in the creation time and save that
> > into
> > > LXCPATH/CONTAINERNAME/hmac. Then both client (can add that value to
> > > message) and server (can read from filesystem to check authenticity of
> > the
> > > file) can use it.
> > >
> > > By binding a restricted port we guarantee that regular users cannot sniff
> > > the traffic and by using the filesystem permissions we provide the
> > desired
> > > separation?
> >
> > But we want regular users to be able to monitor their own containers.
> >
> > Now I suppose we could require an extra netns layer where an
> > unprivileged user must first create a new userns, create a new
> > netns in that, and start containers from there.  Then he has
> > privilege over restricted ports in that netns, so he can monitor
> > containers created from there.  It also gives a somewhat simple
> > way to provide networking to unprivileged-user-created containers-
> > simply have a privileged init script create the userns+netns for
> > the user, keeping it open, create a NIC in there and hook it into
> > a host bridge (since this init job is privileged on the host), then
> > hand the setns fd to the user (by bind-mounting into a DAC-protected
> > directory like /lxc/ns/$USER/).  Now the user can setns into
> > /lxc/ns/$user before running any lxc commands.  It's quite different
> > from what I was earlier envisioning, but doable.  Disclaimer:  I'm
> > groggy this morning, so might be talking sillyness.
> >
> > -serge
> >
> 
> 
> 
> -- 
> S.Çağlar Onur <caglar at 10ur.org>