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

Nels Nelson nels.n.nelson at gmail.com
Mon Apr 28 18:09:58 UTC 2014


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


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?
 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140428/054d206f/attachment.html>


More information about the lxc-users mailing list