qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Moore
Subject: Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist
Date: Tue, 17 Sep 2013 10:43:31 -0400
User-agent: KMail/4.11.1 (Linux/3.10.11-gentoo; KDE/4.11.1; x86_64; ; )

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.

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.

-- 
paul moore
security and virtualization @ redhat




reply via email to

[Prev in Thread] Current Thread [Next in Thread]