All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eduardo Otubo <otubo@linux.vnet.ibm.com>
Cc: pmoore@redhat.com, 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:06:06 +0100	[thread overview]
Message-ID: <20130917130606.GA2812@redhat.com> (raw)
In-Reply-To: <523852A3.3070207@linux.vnet.ibm.com>

On Tue, Sep 17, 2013 at 10:01:23AM -0300, Eduardo Otubo wrote:
> 
> 
> On 09/11/2013 01:49 PM, Daniel P. Berrange wrote:
> >On Wed, Sep 11, 2013 at 12:45:54PM -0400, Corey Bryant wrote:
> >>
> >>
> >>On 09/06/2013 03:21 PM, Eduardo Otubo wrote:
> >>>New command line options for the seccomp blacklist feature:
> >>>
> >>>  $ qemu -sandbox on[,strict=<on|off>]
> >>>
> >>>The strict parameter will turn on or off the new system call blacklist
> >>
> >>I mentioned this before but I'll say it again since I think it needs
> >>to be discussed.  Since this regresses support (it'll prevent -net
> >>bridge and -net tap from using execv) the concern I have with the
> >>strict=on|off option is whether or not we will have the flexibility
> >>to modify the blacklist once QEMU is released with this support.  Of
> >>course we should be able to add more syscalls to the blacklist as
> >>long as they don't regress QEMU functionality.  But if we want to
> >>add a syscall that does regress QEMU functionality, I think we'd
> >>have to add a new command line option, which doesn't seem desirable.
> >>
> >>So a more flexible approach may be necessary.  Maybe the blacklist
> >>should be passed on the command line, which would enable it to be
> >>defined by libvirt and passed to QEMU.  I know Paul is working on
> >>something for libvirt so maybe that answers this question.
> 
> 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.

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.

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

  reply	other threads:[~2013-09-17 13:06 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 [this message]
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
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=20130917130606.GA2812@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.