On 04/26/2013 06:07 PM, Paul Moore wrote:
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.
Unfortunately it is currently not. I'm running the tests manually, but I
have in mind some ideas to implement a tool for this purpose.
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.
Tell me more about this. You're saying I can remove the #ifdefs and keep
the lines like "{ SCMP_SYS(getresuid32), 241 }, " or address these
syscalls in another way?
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).
Yes, that's exactly what I'm planning to do.