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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/