From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMLUO-00038n-69 for qemu-devel@nongnu.org; Wed, 18 Sep 2013 13:24:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMLUF-0005mH-5v for qemu-devel@nongnu.org; Wed, 18 Sep 2013 13:24:32 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:55314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMLUF-0005m9-0A for qemu-devel@nongnu.org; Wed, 18 Sep 2013 13:24:23 -0400 Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Sep 2013 11:24:20 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id CD2863E40044 for ; Wed, 18 Sep 2013 11:24:17 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8IHOGVD352182 for ; Wed, 18 Sep 2013 11:24:17 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8IHOFQx025959 for ; Wed, 18 Sep 2013 11:24:16 -0600 Message-ID: <5239E1BC.1080008@linux.vnet.ibm.com> Date: Wed, 18 Sep 2013 13:24:12 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1378495308-24560-1-git-send-email-otubo@linux.vnet.ibm.com> <2039552.W30lFNyjSm@sifl> <20130918155910.GS20659@redhat.com> <7857946.baCR9dDhyX@sifl> <20130918163216.GV20659@redhat.com> In-Reply-To: <20130918163216.GV20659@redhat.com> Content-Type: text/plain; charset=UTF-8; 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: "Daniel P. Berrange" Cc: Paul Moore , qemu-devel@nongnu.org, Eduardo Otubo On 09/18/2013 12:32 PM, Daniel P. Berrange wrote: > On Wed, Sep 18, 2013 at 12:19:44PM -0400, Paul Moore wrote: >> On Wednesday, September 18, 2013 04:59:10 PM Daniel P. Berrange wrote: >>> On Wed, Sep 18, 2013 at 11:53:09AM -0400, Paul Moore wrote: >>>> On Wednesday, September 18, 2013 08:38:17 AM Daniel P. Berrange wrote: >>>>> Libvirt does not want to be in the business of creating seccomp syscall >>>>> filters for QEMU. As mentioned before, IMHO that places an unacceptable >>>>> burden on libvirt to know about the syscalls each a particular version >>>>> of QEMU requires for its operation. >>>> >>>> At a high level, I don't see how libvirt configuring and installing a >>>> syscall filter is substantially different from libvirt configuring and >>>> installing a network filter. >>> >>> The rules created for a network filter have no bearing or relation to >>> internal QEMU implementation details, as you have with syscalls, so >>> this isn't really a relevant comparison. >> >> The rules created for a network filter are directly related to the details of >> the guest running inside of QEMU. From a practical point of view I see both >> network and syscall filtering as being dependent on the guest; the network >> filtering configuration can change as the guest's services change, the syscall >> filtering configuration can change as the QEMU functionality can change. > > You're talking about two very different things here. Seccomp syscall > filtering affects QEMU itself, while network filter affects the guest > OS apps inside QEMU. Network filtering still does not depend on the > implementation details of the guest OS apps - it depends on the services > that those apps are using. Thus configuring network filters does not > require the admin to have knowledge of the apps internal impl details > in the way that seccomp does. > >>>> Also, and I recognize this is diverting away from a topic most of >>>> qemu-devel is not interested in, what about libvirt-lxc? What about all >>>> of the other virtualization drivers supported by libvirt (granted, not >>>> all would be candidates for syscall filtering, but you get the idea). >>> >>> It isn't clear to me that syscall filtering is something that's relevant >>> for inclusion in libvirt-lxc. It seems like something that would be used >>> by apps running inside LXC containers directly. >> >> For all the same reasons that it makes sense to filter syscalls in QEMU, I >> think it makes sense to filter syscalls in libvirt-lxc. The fundamental >> concern is that the kernel presents are large attack surface in the way of >> syscalls, and it is extremely likely that any given container does not have a >> legitimate need to call into all of the syscalls the kernel presents to >> userspace; especially if you consider the recent approaches of using >> containers to ship/deploy single applications. >> >> Also, just in case there are some misconceptions floating around, loading a >> syscall filter in libvirt doesn't mean the individual container applications >> can't also load their own filter. When multiple syscall filters are present >> for a given process, all of the filters are evaluated and the most restrictive >> decision for a given syscall request "wins". >> >>> Libvirt has no knowledge of such apps or what rules they might require, so >>> can't make any kind of intelligent decision about syscall filtering for LXC. >> >> A perfectly valid point, but I also think of syscall filtering as allowing the >> host administrator the ability to reduce the attack surface of the host >> system/kernel from potentially malicious containers/applications without >> having to rely on these containers/applications to police themselves. >> >>> I really view seccomp as something that apps use directly themselves, not >>> something that a 3rd party process applies prior to launching the apps, >>> since the latter has far too much administrative burden IMHO. >> >> The seccomp filter functionality is definitely something that apps can use >> themselves, but to limit syscall filtering to just that use case is to miss >> out on other valid uses as well. As far as the burden is concerned, is >> users/administrators find it too difficult, there is nothing requiring them to >> use it, however, for those who are facing serious security risks in their >> deployments providing syscall filtering in libvirt might be a very welcome >> addition. > > I'm not debating the usefulness of secomp technology, I just really don't > see it as something that is practical or sensible to encourage end users/ > admins to make use of. It is hard enough for app developers themselves to > make use of it properly and they have a tonne of domain knowledge about > the internals of their application implementation. When you have uninformed > users/admins using it by trial and error I just see a support disaster > coming straight at us. That small minority who really are skilful enough > to use it can still do so by launching the app in question via a 'runseccomp' > like too which would just install a filter & then exec the real binary. > > Regards, > Daniel > An added benefit of allowing an admin to configure a seccomp filter is that they could potentially "patch" a vulnerability before an actual fix is available, by blacklisting a syscall or a syscall argument. -- Regards, Corey Bryant