From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShcNF-0000pK-8S for qemu-devel@nongnu.org; Thu, 21 Jun 2012 04:04:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShcNB-0008CA-GS for qemu-devel@nongnu.org; Thu, 21 Jun 2012 04:04:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46129) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShcNB-0008Ba-8T for qemu-devel@nongnu.org; Thu, 21 Jun 2012 04:04:13 -0400 Message-ID: <4FE2D576.10509@redhat.com> Date: Thu, 21 Jun 2012 11:04:06 +0300 From: Avi Kivity MIME-Version: 1.0 References: <5022524.gIe1TV6Uvp@sifl> <3077496.8pYx57Tfhz@sifl> <4FE05CC8.9040801@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Blue Swirl Cc: Paul Moore , qemu-devel@nongnu.org, Eduardo Otubo On 06/19/2012 09:58 PM, Blue Swirl wrote: >>> At least qemu-ifup/down scripts, migration exec and smbd have been >>> mentioned. Only the system calls made by smbd (for some version of it) >>> can be known. The user could specify arbitrary commands for the >>> others, those could be assumed to use some common (large) subset of >>> system calls but I think the security value would be close to zero >>> then. >> >> We're not trying to protect against the user, but against the guest. If >> we assume the user wrote those scripts with care so they cannot be >> exploited by the guest, then we are okay. > > My concern was that first we could accidentally filter a system call > that changes the script or executable behavior, much like sendmail + > capabilities bug, and then a guest could trigger running this > script/executable and exploit the changed behavior. Ah, I see. I agree this is dangerous. We should probably disable exec if we seccomp. >> >> We have decomposed qemu to some extent, in that privileged operations >> happen in libvirt. So the modes make sense - qemu has no idea whether a >> privileged management system is controlling it or not. > > So with -seccomp, libvirt could tell QEMU that for example open(), > execve(), bind() and connect() will never be needed? Yes. -- error compiling committee.c: too many arguments to function