qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: Eduardo Otubo <otubo@linux.vnet.ibm.com>
Cc: pmoore@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCHv2 2/3] seccomp: adding command line support for blacklist
Date: Wed, 11 Sep 2013 12:45:54 -0400	[thread overview]
Message-ID: <52309E42.2080802@linux.vnet.ibm.com> (raw)
In-Reply-To: <1378495308-24560-3-git-send-email-otubo@linux.vnet.ibm.com>



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.

>
> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
> ---
>   qemu-options.hx |  8 +++++---
>   vl.c            | 11 ++++++++++-
>   2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index d15338e..05485e1 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2978,13 +2978,15 @@ Old param mode (ARM only).
>   ETEXI
>
>   DEF("sandbox", HAS_ARG, QEMU_OPTION_sandbox, \
> -    "-sandbox <arg>  Enable seccomp mode 2 system call filter (default 'off').\n",
> +    "-sandbox <arg>  Enable seccomp mode 2 system call filter (default 'off').\n"
> +    "-sandbox on[,strict=<arg>]\n"
> +    "                Enable seccomp mode 2 system call second level filter (default 'off').\n",

Does this need to mention the QEMU features restricted by the blacklist?

>       QEMU_ARCH_ALL)
>   STEXI
> -@item -sandbox @var{arg}
> +@item -sandbox @var{arg}[,strict=@var{value}]
>   @findex -sandbox
>   Enable Seccomp mode 2 system call filter. 'on' will enable syscall filtering and 'off' will
> -disable it.  The default is 'off'.
> +disable it.  The default is 'off'. 'strict=on' will enable second level filter (default is 'off').

And here too?

>   ETEXI
>
>   DEF("readconfig", HAS_ARG, QEMU_OPTION_readconfig,
> diff --git a/vl.c b/vl.c
> index 02f7486..909f685 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -329,6 +329,9 @@ static QemuOptsList qemu_sandbox_opts = {
>           {
>               .name = "enable",
>               .type = QEMU_OPT_BOOL,
> +        },{
> +            .name = "strict",
> +            .type = QEMU_OPT_STRING,
>           },
>           { /* end of list */ }
>       },
> @@ -1031,6 +1034,7 @@ static int bt_parse(const char *opt)
>
>   static int parse_sandbox(QemuOpts *opts, void *opaque)
>   {
> +    const char * strict_value = NULL;
>       /* FIXME: change this to true for 1.3 */
>       if (qemu_opt_get_bool(opts, "enable", false)) {
>   #ifdef CONFIG_SECCOMP
> @@ -1040,7 +1044,12 @@ static int parse_sandbox(QemuOpts *opts, void *opaque)
>               return -1;
>           }
>
> -        enable_blacklist = true;
> +        strict_value = qemu_opt_get(opts, "strict");
> +        if (strict_value) {
> +            if (!strcmp(strict_value, "on")) {
> +                enable_blacklist = true;
> +            }
> +        }
>   #else
>           qerror_report(ERROR_CLASS_GENERIC_ERROR,
>                         "sandboxing request but seccomp is not compiled into this build");
>

-- 
Regards,
Corey Bryant

  reply	other threads:[~2013-09-11 16:46 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 [this message]
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
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=52309E42.2080802@linux.vnet.ibm.com \
    --to=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).