From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWszk-0004d3-0o for qemu-devel@nongnu.org; Mon, 29 Apr 2013 14:40:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWszg-0004yV-OC for qemu-devel@nongnu.org; Mon, 29 Apr 2013 14:40:11 -0400 Received: from e24smtp03.br.ibm.com ([32.104.18.24]:39466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWszg-0004vi-Ck for qemu-devel@nongnu.org; Mon, 29 Apr 2013 14:40:08 -0400 Received: from /spool/local by e24smtp03.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 29 Apr 2013 15:40:03 -0300 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by d24dlp02.br.ibm.com (Postfix) with ESMTP id BE8DA1DC0060 for ; Mon, 29 Apr 2013 14:39:58 -0400 (EDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.8.31.93]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r3TIbC3e2736318 for ; Mon, 29 Apr 2013 15:37:12 -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 r3TIdvSt003126 for ; Mon, 29 Apr 2013 15:39:57 -0300 Message-ID: <517EBE7D.4020100@linux.vnet.ibm.com> Date: Mon, 29 Apr 2013 15:39:57 -0300 From: Eduardo Otubo MIME-Version: 1.0 References: <517AC9E5.3050204@linux.vnet.ibm.com> <7515044.dYPbKXmJQB@sifl> In-Reply-To: <7515044.dYPbKXmJQB@sifl> 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: Paul Moore Cc: qemu-devel@nongnu.org, Eric Paris 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. > > 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. > >> 3. Debugging and/or learning mode - third party libraries still have the >> problem of interfering in the Qemu's signal mask. According to some >> previous discussions, perhaps patch all external libraries that mass up >> with this mask (spice, for example) is a way to solve it. But not sure >> if it worth the time spent. Would like to hear you guys. > > I think patching all the libraries is a losing battle, I think we need to > pursue alternate debugging techniques. > I agree with you. I was just thinking about working with third party libraries due to this thread: http://lists.gnu.org/archive/html/qemu-devel/2013-02/msg00620.html -- Eduardo Otubo IBM Linux Technology Center