From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgfy8-0006pZ-7N for qemu-devel@nongnu.org; Mon, 18 Jun 2012 13:42:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sgfy1-0006ar-Od for qemu-devel@nongnu.org; Mon, 18 Jun 2012 13:42:27 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:53866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sgfy1-0006aV-Jx for qemu-devel@nongnu.org; Mon, 18 Jun 2012 13:42:21 -0400 Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 18 Jun 2012 13:42:17 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 8F8F56E807C for ; Mon, 18 Jun 2012 13:41:07 -0400 (EDT) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q5IHf7Cm181994 for ; Mon, 18 Jun 2012 13:41:07 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q5IHf6Vd010106 for ; Mon, 18 Jun 2012 13:41:06 -0400 Message-ID: <4FDF682E.4080409@linux.vnet.ibm.com> Date: Mon, 18 Jun 2012 13:41:02 -0400 From: Corey Bryant MIME-Version: 1.0 References: <5022524.gIe1TV6Uvp@sifl> <3077496.8pYx57Tfhz@sifl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/16/2012 02:46 AM, Blue Swirl wrote: > On Fri, Jun 15, 2012 at 9:36 PM, Paul Moore wrote: >> On Friday, June 15, 2012 09:23:46 PM Blue Swirl wrote: >>> On Fri, Jun 15, 2012 at 9:02 PM, 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. >>> >>> The helper program being executed could need any of the 300 system >>> calls, so we'd have to allow all. >> >> Don't we have some basic understanding of what the applications being exec'd >> will need to do? I sorta see your point, but allowing the entire set of >> syscalls seems a bit dramatic. > > 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. > I think at some point in the future we'll want to implement seccomp whitelists for each process that QEMU exec's. The bridge helper (-net bridge) is one that I'm familiar with. It is fairly minimal in the syscalls that it requires. It certainly doesn't need all the syscalls that QEMU needs. It is already severely restricted by SELinux (and AppArmor soon), but restricting the syscall footprint would be a nice addition. -- Regards, Corey >> >>>> Protecting against the abuse and misuse of execve() is something that is >>>> better done with the host's access controls (traditional DAC, MAC via the >>>> LSM, etc.). >>> >>> How about seccomp mode selected by command line switch -seccomp, in >>> which bind/connect/open/execve are forbidden? The functionality >>> remaining would be somewhat limited (can't migrate or use SMB etc. >>> until refactoring of QEMU), but that way seccomp jail would be much >>> tighter. >> >> When I spoke to Anthony about this earlier (offline, sorry) he was opposed to >> requiring any switches or user interaction to enable seccomp. I'm not sure if >> his stance on this has changed any over the past few months. > > There could be two modes, strict mode (-seccomp) and default mode > (only some syscalls blocked). With the future decomposed QEMU, strict > seccomp mode would be default and the switch would be obsoleted. If > the decomposition is planned to happen soonish, adding the switch > would be just churn. > >> >> In my perfect world, we would have a decomposed QEMU that functions as a >> series of processes connected via some sort of IPC; the exact divisions are a >> bit TBD and beyond the scope of this discussion. In this scenario we would be >> able to restrict QEMU with sVirt and seccomp to a much higher degree than we >> could with the current monolithic QEMU. >> >> I don't expect to see my perfect world any time soon, but in the meantime we >> can still improve the security of QEMU on Linux with these seccomp patches and >> for that reason I think it's a win. Since these patches don't expose anything >> at runtime (no knobs, switches, etc.) we leave ourselves plenty of flexibility >> for changing things in the future. > > Yes, I'm much in favor of adding seccomp support soon. But I just > wonder if this is really the best level of security we can reach now, > not assuming decomposed QEMU, but just minor tweaks? > >> >> -- >> paul moore >> security and virtualization @ redhat >> >