On Thu, Sep 06, 2012 at 11:53:06AM -0400, Corey Bryant wrote:
>
>
> On 09/06/2012 02:45 AM, Daniel Veillard wrote:
> >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
> >
>
> We turned this off by default in QEMU 1.2. The thought was that
> we'd get more testing coverage. It's a tough feature to test
> completely, and if a syscall was missed in the whitelist, then your
> guest is dead. The plan is to turn it on by default in QEMU 1.3.
> Perhaps you want to do something similar in libvirt?
The problem is that libvirt and qemu releases are a priori not
tied, doing what you suggest would mean to try to guess the actual
qemu version used by the guest and then switch on or off, which would
somehow be at odd with the overall driver configuration.
This also raises the point of the semantic of -sandbox, the code
assumes that if it is not present then sandboxing is off, and if
it is present sandboxing is on, now what you say seems to imply that
sandboxing is on in 1.3 if not present. If right then we need to instead
do something like -sandbox=off to make sure we propagate the setting
assuming the qemu.conf explicitely states sandbox=0
So we are I think in a tristate configuration:
- sandbox=0 in qemu.conf
and we need to force it off if supported
- sandbox=1 in qemu.conf
and we need to force it on if supported
- commented out in qemu.conf
fallback to the qemu for that guest default
Apparently currently -sandbox takes no arguments, any chance to
suport for -sandbox=off before 1.3 ? Because otherwise the global
settings of libvirt qemu driver will conflict with qemu default setting.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
