All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, Eduardo Otubo <eduardo.otubo@profitbricks.com>
Subject: Re: [Qemu-devel] RFC: How to make seccomp reliable and useful ?
Date: Thu, 16 Feb 2017 09:41:20 +0000	[thread overview]
Message-ID: <20170216094120.GD7346@redhat.com> (raw)
In-Reply-To: <a964ee79-d160-207d-34e8-de480fdf3e23@redhat.com>

On Thu, Feb 16, 2017 at 10:37:31AM +0100, Thomas Huth wrote:
> On 16.02.2017 10:32, Daniel P. Berrange wrote:
> > On Thu, Feb 16, 2017 at 09:38:59AM +0100, Thomas Huth wrote:
> >> I like your proposal! I just wanted to add an idea for an additional
> >> parameter (not sure whether it is feasible, though): Something like
> >> "-sandbox on,network=off" ... i.e. forbid all system calls that are used
> >> for networking. Rationale: Sometimes your VM does not need any
> >> networking, and you want to make sure that a malicious guest can also
> >> not reach your local network in that case.
> > 
> > This is pretty tricky. Even if there is not obviously configured network
> > backend in QEMU, there's plenty of scope for things in libraries to
> > be using networking. Something want a fully qualified hostname ? That'll
> > trigger UDP / TCP connections to a DNS resolver. Running with the SDL
> > or GTK display frontends - those use networking over UNIX sockets to
> > talk to a display server. Linked to glib2 ? That'll connect to DConf
> > over DBus UNIX socket in the background. etc
> 
> Oh, too bad. Aren't there at least some system calls which could be used
> to block TCP/IP connections, while we still allow local UNIX sockets?
> ... hmm, maybe that's rather something to solve at the SELinux level
> instead...

seccomp lets you filter based on value of syscall arguments. So you could
filter out socket() calls with family != AF_UNIX.  This still leaves
potential trouble with DNS resolvers though, which can be valid to use
even if not wanting to make network connections. Annoyingly even if one
ran a localhost DNS resolver, there's no facility in /etc/resolv.conf
to specify a UNIX socket for talking to it - it'd have to use TCP over
localhost :-(

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

      reply	other threads:[~2017-02-16  9:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-15 18:27 [Qemu-devel] RFC: How to make seccomp reliable and useful ? Daniel P. Berrange
2017-02-15 23:36 ` Eduardo Otubo
2017-02-16  9:33   ` Daniel P. Berrange
2017-03-01 22:38     ` Eduardo Otubo
2017-03-02  9:35       ` Daniel P. Berrange
2017-02-16  8:38 ` Thomas Huth
2017-02-16  9:32   ` Daniel P. Berrange
2017-02-16  9:37     ` Thomas Huth
2017-02-16  9:41       ` Daniel P. Berrange [this message]

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=20170216094120.GD7346@redhat.com \
    --to=berrange@redhat.com \
    --cc=eduardo.otubo@profitbricks.com \
    --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.