From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLuyv-0006iB-6U for qemu-devel@nongnu.org; Tue, 17 Sep 2013 09:06:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLuyp-000337-8w for qemu-devel@nongnu.org; Tue, 17 Sep 2013 09:06:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLuyp-00032y-0h for qemu-devel@nongnu.org; Tue, 17 Sep 2013 09:06:11 -0400 Date: Tue, 17 Sep 2013 14:06:06 +0100 From: "Daniel P. Berrange" Message-ID: <20130917130606.GA2812@redhat.com> References: <1378495308-24560-1-git-send-email-otubo@linux.vnet.ibm.com> <1378495308-24560-3-git-send-email-otubo@linux.vnet.ibm.com> <52309E42.2080802@linux.vnet.ibm.com> <20130911164913.GI2293@redhat.com> <523852A3.3070207@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <523852A3.3070207@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo Cc: pmoore@redhat.com, Corey Bryant , qemu-devel@nongnu.org On Tue, Sep 17, 2013 at 10:01:23AM -0300, Eduardo Otubo wrote: > > > On 09/11/2013 01:49 PM, Daniel P. Berrange wrote: > >On Wed, Sep 11, 2013 at 12:45:54PM -0400, Corey Bryant wrote: > >> > >> > >>On 09/06/2013 03:21 PM, Eduardo Otubo wrote: > >>>New command line options for the seccomp blacklist feature: > >>> > >>> $ qemu -sandbox on[,strict=] > >>> > >>>The strict parameter will turn on or off the new system call blacklist > >> > >>I mentioned this before but I'll say it again since I think it needs > >>to be discussed. Since this regresses support (it'll prevent -net > >>bridge and -net tap from using execv) the concern I have with the > >>strict=on|off option is whether or not we will have the flexibility > >>to modify the blacklist once QEMU is released with this support. Of > >>course we should be able to add more syscalls to the blacklist as > >>long as they don't regress QEMU functionality. But if we want to > >>add a syscall that does regress QEMU functionality, I think we'd > >>have to add a new command line option, which doesn't seem desirable. > >> > >>So a more flexible approach may be necessary. Maybe the blacklist > >>should be passed on the command line, which would enable it to be > >>defined by libvirt and passed to QEMU. I know Paul is working on > >>something for libvirt so maybe that answers this question. > > Paul, what exactly are you planning to add to libvirt? I'm not a big > fan of using qemu command line to pass syscalls for blacklist as > arguments, but I can't see other way to avoid problems (like -net > bridge / -net tap) from happening. IMHO, if libvirt is enabling seccomp, then making all possible cli args work is a non-goal. If there are things which require privileges seccomp is blocking, then libvirt should avoid using them. eg by making use of FD passing where appropriate to reduce privileges qemu needs. 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 :|