On Friday, April 26, 2013 03:39:33 PM Eduardo Otubo wrote: > Hello folks, > > Resuming the sandboxing work, I'd like to ask for comments on the > ideias I have: > > 1. Reduce whitelist to the optimal subset: Run various tests on Qemu > with different configurations to reduce to the smallest syscall set > possible; test and send a patch weekly (this is already being performed > and a patch is on the way)
Is this hooked into a testing framework? While it is always nice to have someone verify the correctness, having a simple tool/testsuite what can run through things on a regular basis is even better. Also, looking a bit further ahead, it might be interesting to look at removing some of the arch dependent stuff in qemu-seccomp.c. The latest version of libseccomp should remove the need for many, if not all, of the arch specific #ifdefs and the next version of libseccomp will add support for x32 and ARM. > 2. Introduce a second whitelist - the whitelist should be defined in > libvirt and passed on to qemu or just pre defined in Qemu? Also remove > execve() and avoid open() and socket() and its parameters ... If I'm understanding you correctly, I think what you'll want is a second *blacklist*. We talked about this previously; we currently have a single whitelist, and considering how seccomp works, you can really only further restrict things after you install a whitelist into the kernel (hence the blacklist). > 3. Debugging and/or learning mode - third party libraries still have the > problem of interfering in the Qemu's signal mask. According to some > previous discussions, perhaps patch all external libraries that mass up > with this mask (spice, for example) is a way to solve it. But not sure > if it worth the time spent. Would like to hear you guys. I think patching all the libraries is a losing battle, I think we need to pursue alternate debugging techniques. -- paul moore security and virtualization @ redhat