From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49037) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VM0mQ-0007qe-5h for qemu-devel@nongnu.org; Tue, 17 Sep 2013 15:17:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VM0mH-0000Hb-1W for qemu-devel@nongnu.org; Tue, 17 Sep 2013 15:17:45 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:35292) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VM0mG-0000H9-TL for qemu-devel@nongnu.org; Tue, 17 Sep 2013 15:17:36 -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 ; Tue, 17 Sep 2013 15:17:33 -0400 Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 3985938C8059 for ; Tue, 17 Sep 2013 15:17:30 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp22035.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8HJHUAw19529850 for ; Tue, 17 Sep 2013 19:17:30 GMT Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8HJHT1D006021 for ; Tue, 17 Sep 2013 15:17:29 -0400 Message-ID: <5238AAC8.4060205@linux.vnet.ibm.com> Date: Tue, 17 Sep 2013 15:17:28 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1378495308-24560-1-git-send-email-otubo@linux.vnet.ibm.com> <523852A3.3070207@linux.vnet.ibm.com> <20130917130606.GA2812@redhat.com> <2976992.k7Cxs3D50a@sifl> <52388DF1.4010307@linux.vnet.ibm.com> In-Reply-To: <52388DF1.4010307@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo Cc: Paul Moore , qemu-devel@nongnu.org On 09/17/2013 01:14 PM, Eduardo Otubo wrote: > > > On 09/17/2013 11:43 AM, Paul Moore wrote: >> On Tuesday, September 17, 2013 02:06:06 PM Daniel P. Berrange wrote: >>> On Tue, Sep 17, 2013 at 10:01:23AM -0300, Eduardo Otubo wrote: >>> >>>> 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. >> >> At present, and as far as I'm concerned pretty much everything is open >> for >> discussion, the code works similar to the libvirt network filters. >> You create >> a separate XML configuration file which defines the filter and you >> reference >> that filter from the domain's XML configuration. When a QEMU/KVM or >> LXC based >> domain starts it uses libseccomp to create the seccomp filter and then >> loads >> it into the kernel after the fork but before the domain is exec'd. > > Clever approach. I tihnk a possible way to do this is something like: > > -sandbox > -on[,strict=][,whitelist=qemu_whitelist.conf][,blacklist=qemu_blacklist.conf] > > > where: > > [,whitelist=qemu_whitelist.conf] will override default whitelist filter > [,blacklist=blacklist.conf] will override default blacklist filter > > But when we add seccomp support for qemu on libvirt, we make sure to > just add -sandbox off and use Paul's approach. > > Is that a reasonable approach? What do you think? > QEMU wouldn't require any changes for the approach Paul describes. The QEMU process that is exec'd by libvirt would be constrained by the filter that libvirt installed. -- Regards, Corey Bryant >> >> There are no command line arguments passed to QEMU. This work can >> co-exist >> with the QEMU seccomp filters without problem. >> >> The original goal of this effort wasn't to add libvirt syscall >> filtering for >> QEMU, but rather for LXC; adding QEMU support just happened to be a >> trivial >> patch once the LXC support was added. >> >> (I also apologize for the delays, I hit a snag with an existing >> problem on >> libvirt which stopped work and then some other BZs grabbed my >> attention...) >> >>> 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. >> >> I agree. >> >