qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: How to make seccomp reliable and useful ?


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] RFC: How to make seccomp reliable and useful ?
Date: Thu, 16 Feb 2017 09:41:20 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]