From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33493) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgiKQ-0002by-2F for qemu-devel@nongnu.org; Mon, 18 Jun 2012 16:13:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SgiKN-0004D3-Si for qemu-devel@nongnu.org; Mon, 18 Jun 2012 16:13:37 -0400 Received: from e24smtp03.br.ibm.com ([32.104.18.24]:56752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgiKN-0004CZ-Gf for qemu-devel@nongnu.org; Mon, 18 Jun 2012 16:13:35 -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, 18 Jun 2012 17:13:28 -0300 Received: from d24relay02.br.ibm.com (d24relay02.br.ibm.com [9.13.184.26]) by d24dlp02.br.ibm.com (Postfix) with ESMTP id 624611DC004E for ; Mon, 18 Jun 2012 16:13:25 -0400 (EDT) Received: from d24av03.br.ibm.com (d24av03.br.ibm.com [9.8.31.95]) by d24relay02.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q5IKCm1Y41418970 for ; Mon, 18 Jun 2012 17:12:48 -0300 Received: from d24av03.br.ibm.com (loopback [127.0.0.1]) by d24av03.br.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q5IIDfkS014621 for ; Mon, 18 Jun 2012 15:13:41 -0300 Date: Mon, 18 Jun 2012 17:13:24 -0300 From: Eduardo Otubo Message-ID: <20120618201324.GC12697@bluepex.com> References: <5022524.gIe1TV6Uvp@sifl> <20120618083103.GC28026@redhat.com> <3272318.IIWAhra0IR@sifl> <20120618135535.GX28026@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120618135535.GX28026@redhat.com> Subject: Re: [Qemu-devel] [RFC] [PATCHv2 2/2] Adding basic calls to libseccomp in vl.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Paul Moore , Blue Swirl , qemu-devel@nongnu.org On Mon, Jun 18, 2012 at 02:55:35PM +0100, Daniel P. Berrange wrote: > On Mon, Jun 18, 2012 at 09:52:44AM -0400, Paul Moore wrote: > > On Monday, June 18, 2012 09:31:03 AM Daniel P. Berrange wrote: > > > On Fri, Jun 15, 2012 at 05:02:19PM -0400, Paul Moore wrote: > > > > On Friday, June 15, 2012 07:06:10 PM Blue Swirl wrote: > > > > > I think allowing execve() would render seccomp pretty much useless. > > > > > > > > Not necessarily. > > > > > > > > I'll agree that it does seem a bit odd to allow execve(), but there is > > > > still value in enabling seccomp to disable potentially buggy/exploitable > > > > syscalls. Let's not forget that we have over 300 syscalls on x86_64, not > > > > including the 32 bit versions, and even if we add all of the new syscalls > > > > suggested in this thread we are still talking about a small subset of > > > > syscalls. As far as security goes, the old adage of "less is more" > > > > applies. > > > > > > I can sort of see this argument, but *only* if the QEMU process is being > > > run under a dedicated, fully unprivileged (from a DAC pov) user, completely > > > separate from anything else on the system. > > > > > > Or, of course, for a QEMU already confined by SELinux. > > > > Agreed ... and considering at least one major distribution takes this approach > > it seems like reasonable functionality to me. Confining QEMU, either through > > DAC and/or MAC, when faced with potentially malicious guests is just good > > sense. > > Good, I'm not missing anything then. I'd suggest that future iterations > of these patches explicitly mention the deployment scenarios in which > this technology is able to offer increases security, and also describe > the scenarios where it will not improve things. Please correct me if I'm wrong here, but I don't understand how exactly whitelisting execve() is odd. The white list is inherit and passed along the child processes so they also need to have their own syscalls filtered by BPF in the kernel as stated in the Will's commit log[1] - "Filter programs will be inherited across fork/clone and execve." - I wonder if this is main point of your concern. Whitelisting execve() or not should be no difference from the security pov. However, I agree that a possible future feature could a customized whitelist for each child process spawned. But for a first instance, the default whitelist should be enough to start seccomp support in Qemu. Also, as far as I understand, seccomp never meant to replace any of the technologies above mentioned. Using more than one layer of protection (SELinux, AppArmor MAC policy and/or DAC) should always be a good practice for the defense in depth. [1] - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e2cfabdfd075648216f99c2c03821cf3f47c1727 -- Eduardo Otubo Software Engineer Linux Technology Center IBM Systems & Technology Group Mobile: +55 19 8135 0885 eotubo@linux.vnet.ibm.com