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

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Sep 17, 2013 at 02:14:25PM -0300, Eduardo Otubo wrote:
> 
> 
> On 09/17/2013 11:43 AM, Paul Moore wrote:
> >On Tuesday, September 17, 2013 02:06:06 PM Daniel P. Berrange wrote:
> >>On Tue, Sep 17, 2013 at 10:01:23AM -0300, Eduardo Otubo wrote:
> >>
> >>>Paul, what exactly are you planning to add to libvirt? I'm not a big
> >>>fan of using qemu command line to pass syscalls for blacklist as
> >>>arguments, but I can't see other way to avoid problems (like -net
> >>>bridge / -net tap) from happening.
> >
> >At present, and as far as I'm concerned pretty much everything is open for
> >discussion, the code works similar to the libvirt network filters.  You create
> >a separate XML configuration file which defines the filter and you reference
> >that filter from the domain's XML configuration.  When a QEMU/KVM or LXC based
> >domain starts it uses libseccomp to create the seccomp filter and then loads
> >it into the kernel after the fork but before the domain is exec'd.
> 
> Clever approach. I tihnk a possible way to do this is something like:
> 
>  -sandbox -on[,strict=<on|off>][,whitelist=qemu_whitelist.conf][,blacklist=qemu_blacklist.conf]
> 
> 	where:
> 
> [,whitelist=qemu_whitelist.conf] will override default whitelist filter
> [,blacklist=blacklist.conf] will override default blacklist filter
> 
> But when we add seccomp support for qemu on libvirt, we make sure to
> just add -sandbox off and use Paul's approach.
> 
> Is that a reasonable approach? What do you think?

IMHO the same problem exists for non-libvirt apps using QEMU. Exposing
lists of syscalls as a config option requires applications using QEMU
to know far too much about QEMU's internal implementation details. With
this syntax either apps have to read the source to find out which syscalls
to allow, or they have to use trial & error launching QEMU repeatedly
to see what breaks. Neither of these are nice to applications. IMHO any
configuration of syscalls lists should be exclusively QEMU's responsibility.

What is your actual goal here ? If the goal is to make it possible to
use arbitrary command line arguments, then IMHO, QEMU should just look
at the args given and automatically just "do the right thing" with the
syscall whitelists. Of course per my previous message, I think making
all possible args work under seccomp should be a non-goal.

> >There are no command line arguments passed to QEMU.  This work can co-exist
> >with the QEMU seccomp filters without problem.
> >
> >The original goal of this effort wasn't to add libvirt syscall filtering for
> >QEMU, but rather for LXC; adding QEMU support just happened to be a trivial
> >patch once the LXC support was added.
> >
> >(I also apologize for the delays, I hit a snag with an existing problem on
> >libvirt which stopped work and then some other BZs grabbed my attention...)
> >
> >>IMHO, if libvirt is enabling seccomp, then making all possible cli
> >>args work is a non-goal. If there are things which require privileges
> >>seccomp is blocking, then libvirt should avoid using them. eg by making
> >>use of FD passing where appropriate to reduce privileges qemu needs.
> >
> >I agree.


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