<div dir="ltr"><div class="gmail_extra">Greetings, Serge,-</div><div class="gmail_extra"><br></div><div class="gmail_extra">I went ahead and tested out a blacklist, using the same lxc instance.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">I modified the /var/lib/lxc/test/config to specify the new seccomp policy file:</div><div class="gmail_extra"><br></div><div class="gmail_extra">    lxc.seccomp = /tmp/blacklist</div>







<div class="gmail_extra"><br></div><div class="gmail_extra">However, now the lxc instance refuses to start at all: <a href="https://gist.github.com/nelsnelson/11298117#file-lxc-2-log">https://gist.github.com/nelsnelson/11298117#file-lxc-2-log</a></div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">-Nels</div><div class="gmail_extra"><br></div></div>