From: "Daniel P. Berrange" <berrange@redhat.com>
To: Corey Bryant <coreyb@linux.vnet.ibm.com>
Cc: Paul Moore <pmoore@redhat.com>,
qemu-devel@nongnu.org, Eduardo Otubo <otubo@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist
Date: Wed, 18 Sep 2013 08:38:17 +0100 [thread overview]
Message-ID: <20130918073817.GB20659@redhat.com> (raw)
In-Reply-To: <5238AAC8.4060205@linux.vnet.ibm.com>
On Tue, Sep 17, 2013 at 03:17:28PM -0400, Corey Bryant wrote:
>
>
> On 09/17/2013 01:14 PM, 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?
> >
>
> QEMU wouldn't require any changes for the approach Paul describes.
> The QEMU process that is exec'd by libvirt would be constrained by
> the filter that libvirt installed.
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.
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 :|
next prev parent reply other threads:[~2013-09-18 7:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 19:21 [Qemu-devel] [PATCHv2 0/3] seccomp: adding blacklist support with command line Eduardo Otubo
2013-09-06 19:21 ` [Qemu-devel] [PATCHv2 1/3] seccomp: adding blacklist support Eduardo Otubo
2013-09-09 3:49 ` Lei Li
2013-09-11 16:29 ` Corey Bryant
2013-09-06 19:21 ` [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist Eduardo Otubo
2013-09-11 16:45 ` Corey Bryant
2013-09-11 16:49 ` Daniel P. Berrange
2013-09-17 13:01 ` Eduardo Otubo
2013-09-17 13:06 ` Daniel P. Berrange
2013-09-17 14:43 ` Paul Moore
2013-09-17 17:14 ` Eduardo Otubo
2013-09-17 18:08 ` Eduardo Otubo
2013-09-17 19:17 ` Corey Bryant
2013-09-17 20:16 ` Eduardo Otubo
2013-09-18 7:38 ` Daniel P. Berrange [this message]
2013-09-18 15:53 ` Paul Moore
2013-09-18 15:59 ` Daniel P. Berrange
2013-09-18 16:19 ` Paul Moore
2013-09-18 16:32 ` Daniel P. Berrange
2013-09-18 17:24 ` Corey Bryant
2013-09-18 17:37 ` Paul Moore
2013-09-18 7:35 ` Daniel P. Berrange
2013-09-06 19:21 ` [Qemu-devel] [PATCHv3 3/3] seccomp: general fixes Eduardo Otubo
2013-09-11 16:56 ` Corey Bryant
2013-10-09 0:40 ` Eduardo Otubo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130918073817.GB20659@redhat.com \
--to=berrange@redhat.com \
--cc=coreyb@linux.vnet.ibm.com \
--cc=otubo@linux.vnet.ibm.com \
--cc=pmoore@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).