From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRlOy-0003pr-ND for qemu-devel@nongnu.org; Tue, 08 May 2012 10:28:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRlOs-0005Aj-2K for qemu-devel@nongnu.org; Tue, 08 May 2012 10:28:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRlOr-00058K-Pp for qemu-devel@nongnu.org; Tue, 08 May 2012 10:28:25 -0400 Date: Tue, 8 May 2012 15:27:23 +0100 From: "Daniel P. Berrange" Message-ID: <20120508142723.GJ18762@redhat.com> References: <20120508091535.GB18762@redhat.com> <4FA92951.8090601@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4FA92951.8090601@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC] [PATCH 0/2] Sandboxing Qemu guests with Libseccomp Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Bryant Cc: Eduardo Otubo , "qemu-devel@nongnu.org" , Stefano Stabellini 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. Regards, 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 :|