Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist

["Daniel P. Berrange" <berrange@redhat.com>]

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
-- 
|: 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 :|