From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXXnD-0004We-Nb for qemu-devel@nongnu.org; Wed, 01 May 2013 10:14:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXXnC-0007Qc-K5 for qemu-devel@nongnu.org; Wed, 01 May 2013 10:13:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXXnC-0007QU-CL for qemu-devel@nongnu.org; Wed, 01 May 2013 10:13:58 -0400 From: Paul Moore Date: Wed, 01 May 2013 10:13:03 -0400 Message-ID: <11691265.oTT9LbASug@sifl> In-Reply-To: <51802986.3070701@linux.vnet.ibm.com> References: <517AC9E5.3050204@linux.vnet.ibm.com> <518011C8.7050200@linux.vnet.ibm.com> <51802986.3070701@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] [RFC] Continuous work on sandboxing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Corey Bryant Cc: qemu-devel@nongnu.org, Eric Paris , Eduardo Otubo On Tuesday, April 30, 2013 04:28:54 PM Corey Bryant wrote: > Just to be clear, I'm thinking you could launch guests in one of two > different seccomp sandboxed environments: > > 1) Using the existing and more permissive whitelist where every QEMU > feature works: > > qemu-kvm -sandbox on,default In general, I like the comma delimited list of sandbox filters/methods/etc. but I'm not sure we need to explicitly specify "default", it seems like "on" would be sufficient. It also preserved compatibility with what we have now. > 2) A more restricted whitelist environment that doesn't allow all QEMU > features to work. It would be limited to the whitelist in 1 and it > would also deny things like execve(), open(), socket(), certain ioctl() > parameters, and may only allow reads/writes to specifc fds, and/or block > anything else that could be dangerous: > > qemu-kvm -sandbox on,restricted > > I'm just throwing these command line options and syscalls out there. > And maybe it makes more sense for libvirt to pass the syscalls and > parameters to QEMU so that libvirt can determine the parameters to > restrict, like fd's the guest is allowed to read/write. > > Here's another thread where this was discussed: > http://www.redhat.com/archives/libvir-list/2013-April/msg01501.html Seems reasonable to me. -- paul moore security and virtualization @ redhat