From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRlAc-0008A8-GC for qemu-devel@nongnu.org; Tue, 08 May 2012 10:13:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SRlAW-0007Of-4Y for qemu-devel@nongnu.org; Tue, 08 May 2012 10:13:42 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:57048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRlAW-0007IT-00 for qemu-devel@nongnu.org; Tue, 08 May 2012 10:13:36 -0400 Received: from /spool/local by e6.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 8 May 2012 10:13:30 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 0CA8F6E804C for ; Tue, 8 May 2012 10:10:35 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q48EAY43128750 for ; Tue, 8 May 2012 10:10:34 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q48EAWQ0019470 for ; Tue, 8 May 2012 11:10:34 -0300 Message-ID: <4FA92951.8090601@linux.vnet.ibm.com> Date: Tue, 08 May 2012 10:10:25 -0400 From: Corey Bryant MIME-Version: 1.0 References: <20120508091535.GB18762@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] [PATCH 0/2] Sandboxing Qemu guests with Libseccomp List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: "qemu-devel@nongnu.org" , Eduardo Otubo 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. -- Regards, Corey