On 06/19/2012 09:58 PM, Blue Swirl wrote: >>> At least qemu-ifup/down scripts, migration exec and smbd have been >>> mentioned. Only the system calls made by smbd (for some version of it) >>> can be known. The user could specify arbitrary commands for the >>> others, those could be assumed to use some common (large) subset of >>> system calls but I think the security value would be close to zero >>> then. >> >> We're not trying to protect against the user, but against the guest. If >> we assume the user wrote those scripts with care so they cannot be >> exploited by the guest, then we are okay. > > My concern was that first we could accidentally filter a system call > that changes the script or executable behavior, much like sendmail + > capabilities bug, and then a guest could trigger running this > script/executable and exploit the changed behavior.
Ah, I see. I agree this is dangerous. We should probably disable exec if we seccomp. >> >> We have decomposed qemu to some extent, in that privileged operations >> happen in libvirt. So the modes make sense - qemu has no idea whether a >> privileged management system is controlling it or not. > > So with -seccomp, libvirt could tell QEMU that for example open(), > execve(), bind() and connect() will never be needed? Yes. -- error compiling committee.c: too many arguments to function
