[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] [PATCH 0/2] Sandboxing Qemu guests with Libseccom
Re: [Qemu-devel] [RFC] [PATCH 0/2] Sandboxing Qemu guests with Libseccomp
Tue, 08 May 2012 11:19:29 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0
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:
This is the first effort to sandboxing Qemu guests using Libseccomp. 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.
Re: [Qemu-devel] [RFC] [PATCH 0/2] Sandboxing Qemu guests with Libseccomp, Daniel P. Berrange, 2012/05/08
- [Qemu-devel] [RFC] [PATCH 2/2] Adding basic calls to libseccomp in vl.c, (continued)