[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] [PATCHv2 2/2] Adding basic calls to libseccomp in

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] [PATCHv2 2/2] Adding basic calls to libseccomp in vl.c
Date: Wed, 27 Jun 2012 16:25:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 06/21/2012 03:04 AM, Avi Kivity wrote:
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

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.

There's no great place to jump into this thread so I guess I'll do it here.

There is absolutely no doubt that white-listing syscalls that we currently use provides an improvement in security.

We need to assume:

1) QEMU is run as an unprivileged user

2) QEMU is already heavily restricted by SELinux

In this case, seccomp() is not being used to replace MAC or DAC. It's supplementing both of them by additionally filtering out syscalls that may have unknown kernel exploits in them. That's all this initial effort is about. Since it's scope is so limited, we can simply enable it unconditionally too.

After we have this initial support, then we can look at a -sandbox option. This open could prevent things like open()/execve() but that will come at a cost of features.

I think the reasonable thing to do for -sandbox is to basically focus on the set of syscalls that QEMU would use if it were launched under libvirt. We should obviously make improvements (things like -blockdev) to make this even more restrictive.

Who knows, maybe we end up having multiple types of sandboxes. A '-sandbox libvirt' and a '-sandbox user' where the later is focused on the typical usage of an unprivileged user.

But this is all stuff that can come later. We solve a big problem by just getting the initial whitelist support in.


Anthony Liguori

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]