On Thu, Sep 06, 2012 at 02:27:19PM +0800, Daniel Veillard wrote: > On Mon, Sep 03, 2012 at 02:03:39PM +0200, Ján Tomko wrote: > > QEMU (since 1.2-rc0) supports setting up a syscall whitelist through > > libseccomp on linux kernel from 3.5-rc1. This is enabled by specifying > > -sandbox on on qemu command line. > > > > This patch detects this capability by searching for -sandbox in qemu > > help output and runs qemu with -sandbox on if sandbox is set to non-zero > > in qemu.conf. [...] > As-is the patch looks fine to me, now the real question as you pointed > out is do we want to enforce that at the guest level. > In general, if available sandboxing should be turned on unless we hit > a bug, so if it work as expected, it should always be on, which to me > would be an indication to have that as a global default for the driver > (and on by default). > If you have to rely on the user explicit setting to activate it, it > won't be activated, if security implementations are good enough they > are better off as default settings IMHO, > > So ACK to this, except I would change src/qemu/qemu.conf patch to > enable it by default, i.e. remove the leading # ... then testing will > tell us if we can keep it on. I just asked Chris Evans the vsftpd maintainer since I know he added support for it, except for a couple of bugs on Fedora he activated it by default if the kernel supports it, and things seems to work just fine. So yeah I would keep that a global setting and activated by default, if there are bugs in the kernel or the qemu side we may revisit this but let's see first what kind of bugs pop up, and at the distro level it's easy to switch back to off if there is serious problems. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list