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

[S.Çağlar Onur]

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130417/aa2fa580/attachment.html>