From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWwAT-0000f9-V9 for qemu-devel@nongnu.org; Mon, 29 Apr 2013 18:03:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWwAS-0006WC-9C for qemu-devel@nongnu.org; Mon, 29 Apr 2013 18:03:29 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:40549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWwAS-0006V9-1g for qemu-devel@nongnu.org; Mon, 29 Apr 2013 18:03:28 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Apr 2013 18:03:27 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 6FA746E803C for ; Mon, 29 Apr 2013 18:03:21 -0400 (EDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3TM3Nur163846 for ; Mon, 29 Apr 2013 18:03:24 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r3TM3InT021680 for ; Mon, 29 Apr 2013 16:03:18 -0600 Message-ID: <517EEE0C.603@linux.vnet.ibm.com> Date: Mon, 29 Apr 2013 18:02:52 -0400 From: Corey Bryant MIME-Version: 1.0 References: <517AC9E5.3050204@linux.vnet.ibm.com> <7515044.dYPbKXmJQB@sifl> <517EBE7D.4020100@linux.vnet.ibm.com> In-Reply-To: <517EBE7D.4020100@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo Cc: Paul Moore , qemu-devel@nongnu.org, Eric Paris On 04/29/2013 02:39 PM, Eduardo Otubo wrote: > > > On 04/26/2013 06:07 PM, Paul Moore wrote: >> On Friday, April 26, 2013 03:39:33 PM Eduardo Otubo wrote: >>> Hello folks, >>> >>> Resuming the sandboxing work, I'd like to ask for comments on the >>> ideias I have: >>> >>> 1. Reduce whitelist to the optimal subset: Run various tests on Qemu >>> with different configurations to reduce to the smallest syscall set >>> possible; test and send a patch weekly (this is already being performed >>> and a patch is on the way) >> >> Is this hooked into a testing framework? While it is always nice to have >> someone verify the correctness, having a simple tool/testsuite what >> can run >> through things on a regular basis is even better. > > Unfortunately it is currently not. I'm running the tests manually, but I > have in mind some ideas to implement a tool for this purpose. > How about testing in KVM autotest? I assume it would be as simple as modifying some existing tests to use -sandbox on. We definitely should get some automated regression tests running with seccomp on. >> >> Also, looking a bit further ahead, it might be interesting to look at >> removing >> some of the arch dependent stuff in qemu-seccomp.c. The latest >> version of >> libseccomp should remove the need for many, if not all, of the arch >> specific >> #ifdefs and the next version of libseccomp will add support for x32 >> and ARM. > > Tell me more about this. You're saying I can remove the #ifdefs and keep > the lines like "{ SCMP_SYS(getresuid32), 241 }, " or address these > syscalls in another way? > >> >>> 2. Introduce a second whitelist - the whitelist should be defined in >>> libvirt and passed on to qemu or just pre defined in Qemu? Also remove >>> execve() and avoid open() and socket() and its parameters ... >> >> If I'm understanding you correctly, I think what you'll want is a second >> *blacklist*. We talked about this previously; we currently have a single >> whitelist, and considering how seccomp works, you can really only further >> restrict things after you install a whitelist into the kernel (hence the >> blacklist). > > Yes, that's exactly what I'm planning to do. > Hmm, I thought you were going to introduce a completely new whitelist so that a guest could optionally be run under: 1) the existing sandbox environment where everything in QEMU works, *or* 2) a new tighter and more restricted sandbox environment where things like execve() is denied, open() is denied (once the pre-req's are in place for fd passing), and potentially other "dangerous" syscalls are denied. If the whitelist for #2 was passed from libvirt to qemu then libvirt could define the syscalls and syscall parameters that are denied. -- Regards, Corey Bryant