From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQNsN-0004sq-E7 for qemu-devel@nongnu.org; Fri, 04 May 2012 15:09:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SQNsL-0001nL-Ev for qemu-devel@nongnu.org; Fri, 04 May 2012 15:09:10 -0400 Received: from e24smtp04.br.ibm.com ([32.104.18.25]:42930) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SQNsL-0001fn-3T for qemu-devel@nongnu.org; Fri, 04 May 2012 15:09:09 -0400 Received: from /spool/local by e24smtp04.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 May 2012 16:08:59 -0300 Received: from d24relay02.br.ibm.com (d24relay02.br.ibm.com [9.13.184.26]) by d24dlp02.br.ibm.com (Postfix) with ESMTP id 72BDD1DC004F for ; Fri, 4 May 2012 16:08:52 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.8.31.93]) by d24relay02.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q44J8YYu15139232 for ; Fri, 4 May 2012 16:08:34 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q44J8t2i004209 for ; Fri, 4 May 2012 16:08:56 -0300 From: Eduardo Otubo Date: Fri, 4 May 2012 16:08:36 -0300 Message-Id: Subject: [Qemu-devel] [RFC] [PATCH 0/2] Sandboxing Qemu guests with Libseccomp List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Eduardo Otubo 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. It's important to note that the libseccomp itself needs the seccomp mode 2 feature in the kernel, which is pretty close to get to the mainline since it's already been accepted to the linux-next branch[1]. As always, comments are more than welcome. Regards, [0] - http://sourceforge.net/projects/libseccomp/ [1] - http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=e2cfabdfd075648216f99c2c03821cf3f47c1727 Eduardo Otubo (2): Adding support for libseccomp in configure Adding basic calls to libseccomp in vl.c configure | 23 ++++++++++++++++++ vl.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 104 insertions(+) -- 1.7.9.5