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

[Paul Moore]

On Wednesday, September 18, 2013 05:32:17 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.

>From a security standpoint I'm not entirely convinced the distinction is 
important.

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

Once again, I'm not entirely sure that worrying about the distinction between 
guest apps/services is important - it is just the "guest".

> Thus configuring network filters does not require the admin to have
> knowledge of the apps internal impl details in the way that seccomp does.

Network filters require the admin to have knowledge of what apps/services the 
guest is providing.  Syscall filters require the admin have knowledge of what 
version of QEMU is deployed on the host.  I think it is reasonable to expect 
that the admin has more knowledge, and more control, over the QEMU version 
they are using than they do over what is being run in the hosted guests.

I don't argue that arriving at the correct syscall filter configuration is 
more difficult than a network filter, but I don't see what that means we can't 
offer it as an option for the more savy admins.  Also, the libvirt patches I'm 
currently working on allow the syscall filter to be defined either as a 
whitelist or a blacklist; the blacklist approach should provide a much more 
gradual learning curve ... and in the case of containers, I suspect it might 
also be the better solution.

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

I think providing support in libvirt and encouraging every libvirt user to 
make use of it are two different things.

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

Once again, I'm not sure adding support for the functionality means we have to 
advocate that every user enable it on their systems.  I would recommend that 
we document the functionality well, like the rest of libvirt, and make sure 
the documentation is very clear about the care needed in crafting the filters, 
perhaps even documenting some troubleshooting/discovery approaches as well as 
the use of blacklists over whitelists as a starting point.

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

Does libvirt currently have a mechanism to execute such a helper program 
before a container is exec'd?  What about QEMU and the rest of the libvirt 
supported virt drivers?

-- 
paul moore
security and virtualization @ redhat