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