From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgueg-0006hY-F0 for qemu-devel@nongnu.org; Tue, 19 Jun 2012 05:23:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sguea-0000sF-5S for qemu-devel@nongnu.org; Tue, 19 Jun 2012 05:23:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgueZ-0000rn-TI for qemu-devel@nongnu.org; Tue, 19 Jun 2012 05:23:16 -0400 Date: Tue, 19 Jun 2012 10:23:09 +0100 From: "Daniel P. Berrange" Message-ID: <20120619092309.GB12096@redhat.com> References: <20120613203028.GB6019@redhat.com> <5022524.gIe1TV6Uvp@sifl> <20120618083103.GC28026@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable 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: Blue Swirl Cc: Paul Moore , qemu-devel@nongnu.org, Eduardo Otubo On Mon, Jun 18, 2012 at 08:15:37PM +0000, Blue Swirl wrote: > On Mon, Jun 18, 2012 at 8:31 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 s= yscalls. > >> Let's not forget that we have over 300 syscalls on x86_64, not inclu= ding the > >> 32 bit versions, and even if we add all of the new syscalls suggeste= d in this > >> thread we are still talking about a small subset of syscalls. =C2=A0= 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 be= ing > > run under a dedicated, fully unprivileged (from a DAC pov) user, comp= letely > > separate from anything else on the system. > > > > If QEMU were being run as root, then even with seccomp, it could triv= ially > > just overwrite some binary in /bin, update /proc/core-pattern to poin= t to >=20 > Not wiithout 'open'. When run as root, it would be nice to chroot() > also to some empty directory and then drop chroot() privileges. That's just another example of my point, that adding seccomp alone does nothing for QEMU security. It is only valuable when combined with another security technique, be it per-user DAC separation, SELinux MAC, or chroot, or splitting QEMU into multiple separate processes, or using Linux containers to confine it, etc Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|