Re: [Qemu-devel] [RFC] [PATCH 0/2] Sandboxing Qemu guests with Libseccomp

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

On 05/08/2012 10:27 AM, Daniel P. Berrange wrote:
> On Tue, May 08, 2012 at 10:10:25AM -0400, Corey Bryant wrote:
>>
>>
>> On 05/08/2012 07:32 AM, Stefano Stabellini wrote:
>>> On Tue, 8 May 2012, Daniel P. Berrange wrote:
>>>> On Fri, May 04, 2012 at 04:08:36PM -0300, Eduardo Otubo wrote:
>>>>> Hello all,
>>>>>
>>>>> This is the first effort to sandboxing Qemu guests using Libseccomp[0]. The
>>>>> patches that follows are pretty simple and straightforward. I added the correct
>>>>> options and checks to the configure script and the basic calls to libseccomp in
>>>>> the main loop at vl.c. Details of each one are in the emails of the patch set.
>>>>>
>>>>> This support limits the system call footprint of the entire QEMU process to a
>>>>> limited set of syscalls, those that we know QEMU uses.  The idea is to limit
>>>>> the allowable syscalls, therefore limiting the impact that an attacked guest
>>>>> could have on the host system.
>>>>
>>>> What functionality has been lost by applying this seccomp filter ? I've not
>>>> looked closely at the code, but it appears as if this blocks pretty much
>>>> any kind of runtime device changes. ie no hotplug of any kind will work ?
>>>
>>> Right, I was wondering the same thing: open is not on the list so adding
>>> a new disk shouldn't be possible.
>>>
>>> Regarding Xen, most of the hypercalls go through xc_* calls that are
>>> ioctls on the privcmd device. Is it possible to add ioctl to the list?
>>>
>>
>> If the whitelist is complete there should be no functionality lost
>> when using seccomp with QEMU.  The idea (at least at this point) is
>> to disallow the system calls that QEMU doesn't use.  open and ioctl
>> should be added to the whitelist.
>
> Ok. So my next question is what is the benchmark for evaluating
> whether this seccomp code provides any kind of meaningful security
> improvement ? AFAICT, if you were allow open(), or indeed every
> syscall any QEMU feature could possibly use, then there would be
> little-to-no security benefit.

Well let's say we have a seccomp whitelist of 50 syscalls.  That reduces 
the syscall footprint from ~350 (on x86) syscalls to 50, limiting what 
the attacker could execute from an exploited guest.

Eventually it would be nice to fine-tune the syscall parameters that are 
whitelisted.  For example, we could only allow a designated subset of 
allowable ioctls.  Or we could allow I/O operations only on a designated 
set of file descriptors that the guest needs to access.

-- 
Regards,
Corey