Quoting Nels Nelson ([email protected]): > 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 > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
