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