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

[Paul Moore]

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.

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

-- 
paul moore
security and virtualization @ redhat