From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:49128)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1SRgWM-0005VM-5f
	for qemu-devel@nongnu.org; Tue, 08 May 2012 05:15:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1SRgWF-0005eG-BN
	for qemu-devel@nongnu.org; Tue, 08 May 2012 05:15:49 -0400
Received: from mx1.redhat.com ([209.132.183.28]:4854)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1SRgWE-0005e1-VI
	for qemu-devel@nongnu.org; Tue, 08 May 2012 05:15:43 -0400
Date: Tue, 8 May 2012 10:15:35 +0100
From: "Daniel P. Berrange" <berrange@redhat.com>
Message-ID: <20120508091535.GB18762@redhat.com>
References: <cover.1336143671.git.otubo@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <cover.1336143671.git.otubo@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC] [PATCH 0/2] Sandboxing Qemu guests with
 Libseccomp
Reply-To: "Daniel P. Berrange" <berrange@redhat.com>
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eduardo Otubo <otubo@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org

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 ?

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|