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

[S.Çağlar Onur]

Hi Daniel,


On Mon, Apr 15, 2013 at 5:14 AM, Daniel Lezcano <daniel.lezcano at free.fr>wrote:

> On 04/15/2013 07:53 AM, S.Çağlar Onur wrote:
> > Hi Daniel,
> >
> >
> > On Sun, Apr 14, 2013 at 4:42 PM, Daniel Lezcano
> > <daniel.lezcano at free.fr <mailto:daniel.lezcano at free.fr>> wrote:
> >
> >     On 04/14/2013 09:56 PM, S.Çağlar Onur wrote:
> >     > Hi all,
> >     >
> >     > I had some free time today so I tried to implement something using
> >     > AF_INET messages over loopback broadcast address. I'm not including
> >     > the patch here because gmail web interface damages it and that's
> >     what
> >     > I use right now so please use [1] to see it.
> >     >
> >     > I'm sending it to get your feedback and will submit it to list
> >     if you
> >     > are OK with that approach.
> >     >
> >     > P.S: I used 51423 as the port but of course it can be changed
> >     > accordingly.
> >     >
> >     > [1]
> >     >
> >
> https://github.com/caglar10ur/lxc-upstream/commit/123b20e2945ed2b4bc9e6e27b9ef398ec8fcae40.patch
> >
> >     Thanks for this code !
> >
> >     It sounds like the approach seems ok. My concern is the same than
> >     Serge,
> >     what can we do to ensure an event was sent by a container ?
> >
> >     We don't want someone to send fake events via UDP. We can't tolerate
> a
> >     simple program messing a container supervisor and all the containers
> >     (running an OS instance).
> >
> >     Assuming an user, which is not root, can't build an IP packet, we can
> >     rely on the IP identification number to detect fake packets, no ?
> >
> >
> > I'm not sure about the right answer of that question. I was under the
> > impression that we are safe since kernel only allows root user to send
> > broadcast packages over loopback interface but I might
> > be completely wrong.
>
> I don't find a confirmation about this anywhere. Do you have a pointer ?
> If it is the case, then that's cool because we are safe on this side.
>

Unfortunately I don't have any but I'll try to write a test client to see
what will happen. What should we do if that's not the case? I'm not a
security guy at all so I really don't know whether just checking the
sequence numbers will be sufficient or something more sophisticated is
needed to ensure the authenticity of the messages.

Is your code tested ? I mean, did you validate monitoring the events
> works with this approach ?
>

I tested lxc-monitor and lxc-wait briefly with this code. On one terminal I
start 9 containers in parallel while running lxc-monitor and lxc-wait in
another one

caglar at qgq:~/Project/lxc/examples$ sudo ./concurrent_start
Starting the container (3)...
Starting the container (7)...
Starting the container (0)...
Starting the container (1)...
Starting the container (2)...
Starting the container (8)...
Starting the container (4)...
Starting the container (5)...
Starting the container (9)...
Starting the container (6)...

caglar at qgq:~$ sudo lxc-monitor -n [0-9]
'3' changed state to [STARTING]
'0' changed state to [STARTING]
'7' changed state to [STARTING]
'1' changed state to [STARTING]
'2' changed state to [STARTING]
'8' changed state to [STARTING]
'4' changed state to [STARTING]
'5' changed state to [STARTING]
'9' changed state to [STARTING]
'6' changed state to [STARTING]
'3' changed state to [RUNNING]
'9' changed state to [RUNNING]
'7' changed state to [RUNNING]
'2' changed state to [RUNNING]
'5' changed state to [RUNNING]
'6' changed state to [RUNNING]
'4' changed state to [RUNNING]
'0' changed state to [RUNNING]
'8' changed state to [RUNNING]
'1' changed state to [RUNNING]

caglar at qgq:~$ sudo lxc-wait -n 0 -s RUNNING
caglar at qgq:~$



> Thanks
>   -- Daniel
>
>
Best,
-- 
S.Çağlar Onur <caglar at 10ur.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20130415/eb82846a/attachment.html>