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?
--
Regards,
Corey