From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLyrJ-0001jL-9W for qemu-devel@nongnu.org; Tue, 17 Sep 2013 13:14:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLyrA-0001rP-CC for qemu-devel@nongnu.org; Tue, 17 Sep 2013 13:14:41 -0400 Received: from e24smtp02.br.ibm.com ([32.104.18.86]:53106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLyrA-0001qy-0e for qemu-devel@nongnu.org; Tue, 17 Sep 2013 13:14:32 -0400 Received: from /spool/local by e24smtp02.br.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 17 Sep 2013 14:14:28 -0300 Received: from d24relay03.br.ibm.com (d24relay03.br.ibm.com [9.13.184.25]) by d24dlp01.br.ibm.com (Postfix) with ESMTP id 441443520064 for ; Tue, 17 Sep 2013 13:14:26 -0400 (EDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.8.31.91]) by d24relay03.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8HHCqMP36765842 for ; Tue, 17 Sep 2013 14:12:52 -0300 Received: from d24av01.br.ibm.com (localhost [127.0.0.1]) by d24av01.br.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r8HHEP5M013872 for ; Tue, 17 Sep 2013 14:14:25 -0300 Message-ID: <52388DF1.4010307@linux.vnet.ibm.com> Date: Tue, 17 Sep 2013 14:14:25 -0300 From: Eduardo Otubo 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> In-Reply-To: <2976992.k7Cxs3D50a@sifl> 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: Paul Moore Cc: Corey Bryant , qemu-devel@nongnu.org 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? > > 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. > -- Eduardo Otubo IBM Linux Technology Center