All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Eduardo Otubo <eduardo.otubo@profitbricks.com>,
	qemu-devel@nongnu.org, thuth@redhat.com,
	Andy Lutomirski <luto@amacapital.net>
Subject: Re: [Qemu-devel] [PATCH 3/5] seccomp: add elevateprivileges argument to command line
Date: Tue, 14 Mar 2017 13:13:15 +0100	[thread overview]
Message-ID: <d8825eda-6613-71c9-9dd7-9239325e296b@redhat.com> (raw)
In-Reply-To: <20170314115253.GL2652@redhat.com>



On 14/03/2017 12:52, Daniel P. Berrange wrote:
>>>  DEF("sandbox", HAS_ARG, QEMU_OPTION_sandbox, \
>>> -    "-sandbox on[,obsolete=allow]  Enable seccomp mode 2 system call filter (default 'off').\n" \
>>> -    "                              obsolete: Allow obsolete system calls",
>>> +    "-sandbox on[,obsolete=allow][,elevateprivileges=deny]\n" \
>>> +    "                               Enable seccomp mode 2 system call filter (default 'off').\n" \
>>> +    "                               obsolete: Allow obsolete system calls\n" \
>>> +    "                               elevateprivileges: avoids Qemu process to elevate its privileges by blacklisting all set*uid|gid system calls",
>> Why allow these by default?
> The goal is that '-sandbox on' should not break *any* QEMU feature. It
> needs to be a safe thing that people can unconditionally turn on without
> thinking about it.

Sure, but what advantages would it provide if the default blacklist does
not block anything meaningful?  At the very least, spawn=deny should
default elevateprivileges to deny too.

I think there should be a list (as small as possible) of features that
are sacrificed by "-sandbox on".

> The QEMU bridge helper  requires setuid privs, hence
> elevated privileges needs to be permitted by default.

QEMU itself should not be getting additional privileges, only the helper
and in turn the helper or ifup scripts can be limited through MAC.  The
issue is that seccomp persists across execve.

Currently, unprivileged users are only allowed to install seccomp
filters if no_new_privs is set.  Would it make sense if seccomp filters
without no_new_privs succeeded, except that the filter would not persist
across execve of binaries with setuid, setgid or file capabilities?

Then the spawn option could be a tri-state with the choice of allow,
deny and no_new_privs:

- elevateprivileges=allow,spawn=allow: legacy for old kernels
- elevateprivileges=deny,spawn=allow: can run privileged helpers
- elevateprivileges=deny,spawn=deny: cannot run helpers at all
- elevateprivileges=deny,spawn=no_new_privs: can run unprivileged
helpers only

Paolo

> Similarly I could
> see the qemu ifup  scripts, or migrate 'exec' command wanting to elevate
> privs via setuid binaries if QEMU was running unprivileged.

  reply	other threads:[~2017-03-14 12:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-14 11:32 [Qemu-devel] [PATCH 0/5] seccomp: feature refactoring Eduardo Otubo
2017-03-14 11:32 ` [Qemu-devel] [PATCH 1/5] seccomp: changing from whitelist to blacklist Eduardo Otubo
2017-03-14 11:32 ` [Qemu-devel] [PATCH 2/5] seccomp: add obsolete argument to command line Eduardo Otubo
2017-03-14 11:47   ` Paolo Bonzini
2017-03-14 12:01   ` Thomas Huth
2017-03-14 12:22     ` Eduardo Otubo
2017-03-14 11:32 ` [Qemu-devel] [PATCH 3/5] seccomp: add elevateprivileges " Eduardo Otubo
2017-03-14 11:47   ` Paolo Bonzini
2017-03-14 11:52     ` Daniel P. Berrange
2017-03-14 12:13       ` Paolo Bonzini [this message]
2017-03-14 12:24         ` Daniel P. Berrange
2017-03-14 12:42           ` Eduardo Otubo
2017-03-14 12:32         ` Eduardo Otubo
2017-03-14 12:48           ` Paolo Bonzini
2017-03-14 13:02             ` Daniel P. Berrange
2017-03-14 13:05               ` Paolo Bonzini
2017-03-14 13:19                 ` Daniel P. Berrange
2017-03-14 11:32 ` [Qemu-devel] [PATCH 4/5] seccomp: add spawn " Eduardo Otubo
2017-03-14 11:32 ` [Qemu-devel] [PATCH 5/5] seccomp: add resourcecontrol " Eduardo Otubo
2017-03-14 11:40 ` [Qemu-devel] [PATCH 0/5] seccomp: feature refactoring no-reply

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=d8825eda-6613-71c9-9dd7-9239325e296b@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eduardo.otubo@profitbricks.com \
    --cc=luto@amacapital.net \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /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.