From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39863) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVpsk-00006F-0f for qemu-devel@nongnu.org; Fri, 26 Apr 2013 17:08:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UVpsj-0000jt-59 for qemu-devel@nongnu.org; Fri, 26 Apr 2013 17:08:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60534) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVpsi-0000jk-T2 for qemu-devel@nongnu.org; Fri, 26 Apr 2013 17:08:37 -0400 From: Paul Moore Date: Fri, 26 Apr 2013 17:07:50 -0400 Message-ID: <7515044.dYPbKXmJQB@sifl> In-Reply-To: <517AC9E5.3050204@linux.vnet.ibm.com> References: <517AC9E5.3050204@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: qemu-devel@nongnu.org, Eric Paris 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. 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. > 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). > 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. -- paul moore security and virtualization @ redhat