[lxc-users] Failure to start a container with 'lxc.seccomp' option set

[Serge Hallyn]

Quoting Nels Nelson (nels.n.nelson at gmail.com):
> Greetings, Serge,-
> 
> I went ahead and tested out a blacklist, using the same lxc instance.
> 
> I modified the /var/lib/lxc/test/config to specify the new seccomp policy
> file:
> 
>     lxc.seccomp = /tmp/blacklist
> 
> However, now the lxc instance refuses to start at all:
> https://gist.github.com/nelsnelson/11298117#file-lxc-2-log

Hm, I wonder if you're on an old libseccomp, or have an older copy
sitting around.  Try doing

sed -i 's/mknod/mknod errno 0/' /tmp/blacklist

and see if it now loads.  (errno 0 means it won't allow the mknod,
but will return success as though it had worked)

> I suppose my question is now: Is LXC somehow actually applying the seccomp
> restrictions to the container resources prior to init?  And if so, why?

Prior to init, yes, but very close to the end.  In fact right before
we run the start hooks.  Since the start hooks come from the container
rootfs, we have to run them under seccomp.  After that we close the
sigfd (so close has to be allowed), but that's about it.

>  Shouldn't it start the container, and then begin to allow seccomp to
> enforce the syscall whitelisting for operations within the container?
> 
> I suppose this might be sort of a chicken and egg problem, in that, if I
> wish to restrict a user's container, but still allow for a particular
> template to be provisioned and deployed by said user, then the init process
> may be entirely subversive, with respect to the sandboxing goal.
> 
> With that in mind, can you give me an example of a simple seccomp
> white/black-list policy which would allow the lxc instance to init
> completely, but which would verifiably prevent some operation within the
> container, post-init?
> 
> Thanks,
> -Nels

> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users