qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Otubo <otubo@linux.vnet.ibm.com>
To: Paul Moore <pmoore@redhat.com>
Cc: Corey Bryant <coreyb@linux.vnet.ibm.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist
Date: Tue, 17 Sep 2013 14:14:25 -0300	[thread overview]
Message-ID: <52388DF1.4010307@linux.vnet.ibm.com> (raw)
In-Reply-To: <2976992.k7Cxs3D50a@sifl>



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?

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

-- 
Eduardo Otubo
IBM Linux Technology Center

  reply	other threads:[~2013-09-17 17:14 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 [this message]
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
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=52388DF1.4010307@linux.vnet.ibm.com \
    --to=otubo@linux.vnet.ibm.com \
    --cc=coreyb@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).