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

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

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