qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Otubo <eduardo.otubo@profitbricks.com>
To: Namsun Ch'o <namnamc@Safe-mail.net>
Cc: pmoore@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox
Date: Tue, 29 Sep 2015 17:38:07 +0200	[thread overview]
Message-ID: <20150929153807.GB10053@vader> (raw)
In-Reply-To: <N1-IUU_41wMS2@Safe-mail.net>

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

(I'm not sure what happens to your emails that all of them does not
relate to the same thread/Message-ID, making a pain to follow through
out the volume of email on the list, please pay attention to that)

On Mon, Sep 28, 2015 at 11=14=42PM -0400, Namsun Ch'o wrote:
> > My understanding of the config file you proposed is that it would allow the
> > configuration of a whitelist, so changes to the config very could result in
> > *less* strict of a filter, not always more.
> 
> No. Any time an administrator wants a syscall that is not enabled in the
> sandbox, they either don't actually need it, or it's a bug and should be
> fixed. So all the config would do is add argument filters to syscalls which
> are already whitelisted. The alternative would be that the syscalls are given
> no further argument filtering. The config could only make the filteres more
> restrictive, never less.

By its concept, adding exception to the whitelist always makes it less
restrictive by definition, but I got your point. Another point here,
though, is that whitelisting syscall is not as common as you think it
is. I've been maintaining this sub-system for more than an year now and
I had to review/commit/push very few times.

Seccomp sandboxing is enabled by default on virt-test, so whoever is
using that framework is also testing their workload against the current
syscall whitelist. If no one has hit any problem so far, it means the
whitelist is in good shape for usual workloads and configurations.

I'm not particularly against any improvement like configuration files or
more command line args, but I'm concerned about the security itself. If
some guest can scape to the host, it's gonna be much easier to whitelist
syscalls for the next guests, changing the command line is a little too
obvious -- paranoid example, I know.

If you want to write an RFC with your idea, you're more than welcome. We
could move on this discussion and perhaps come up with a nice solution.

Regards,

> 
> Perhaps there could be a #define somewhere that toggles whether or not a
> syscall argument filter can be created for a syscall which is not in the
> built-in whitelist, otherwise it would throw an error saying that you cannot
> create an argument filter for a syscall that is not permitted.

-- 
Eduardo Otubo
ProfitBricks GmbH

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-09-29 15:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-29  3:14 [Qemu-devel] [PATCH v2] Add argument filters to the seccomp sandbox Namsun Ch'o
2015-09-29 15:38 ` Eduardo Otubo [this message]
2015-09-29 22:12 ` Paul Moore
     [not found] <d55ad1eed872006f0634c3e0067553a5@airmail.cc>
2015-10-01  7:17 ` Markus Armbruster
  -- strict thread matches above, loose matches on Subject: below --
2015-09-30  6:41 Namsun Ch'o
2015-10-01  5:58 ` Markus Armbruster
2015-09-28 21:34 Namsun Ch'o
2015-09-29  1:19 ` Paul Moore
2015-09-26  5:06 Namsun Ch'o
2015-09-28 18:24 ` Paul Moore
2015-09-25  4:53 Namsun Ch'o
2015-09-25 17:03 ` Paul Moore
2015-09-11  0:54 namnamc
2015-09-24  9:59 ` 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=20150929153807.GB10053@vader \
    --to=eduardo.otubo@profitbricks.com \
    --cc=namnamc@Safe-mail.net \
    --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).