From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgcQl-0000XB-KD for qemu-devel@nongnu.org; Mon, 18 Jun 2012 09:55:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SgcQi-0002FS-OZ for qemu-devel@nongnu.org; Mon, 18 Jun 2012 09:55:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgcQi-0002FM-AH for qemu-devel@nongnu.org; Mon, 18 Jun 2012 09:55:44 -0400 Date: Mon, 18 Jun 2012 14:55:35 +0100 From: "Daniel P. Berrange" Message-ID: <20120618135535.GX28026@redhat.com> References: <5022524.gIe1TV6Uvp@sifl> <20120618083103.GC28026@redhat.com> <3272318.IIWAhra0IR@sifl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3272318.IIWAhra0IR@sifl> Subject: Re: [Qemu-devel] [RFC] [PATCHv2 2/2] Adding basic calls to libseccomp in vl.c Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Moore Cc: Blue Swirl , qemu-devel@nongnu.org, Eduardo Otubo 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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|