Re: [Qemu-devel] [PATCH v1] os-posix: Add -unshare option

[Daniel P. Berrange]

On Mon, Oct 23, 2017 at 04:01:12PM +0100, Ross Lagerwall wrote:
> On 10/23/2017 03:50 PM, Daniel P. Berrange wrote:
> > On Mon, Oct 23, 2017 at 03:30:05PM +0100, Ross Lagerwall wrote:
> > > On 10/19/2017 05:24 PM, Daniel P. Berrange wrote:
> > > > On Thu, Oct 19, 2017 at 05:04:19PM +0100, Ross Lagerwall wrote:
> > > > > Add an option to allow calling unshare() just before starting guest
> > > > > execution. The option allows unsharing one or more of the mount
> > > > > namespace, the network namespace, and the IPC namespace. This is 
> > > > > useful
> > > > > to restrict the ability of QEMU to cause damage to the system should 
> > > > > it
> > > > > be compromised.
> > > > > 
> > > > > An example of using this would be to have QEMU open a QMP socket at
> > > > > startup and unshare the network namespace. The instance of QEMU could
> > > > > still be controlled by the QMP socket since that belongs in the 
> > > > > original
> > > > > namespace, but if QEMU were compromised it wouldn't be able to open 
> > > > > any
> > > > > new connections, even to other processes on the same machine.
> > > > 
> > > > Unless I'm misunderstanding you, what's described here is already 
> > > > possible
> > > > by just using the 'unshare' command to spawn QEMU:
> > > > 
> > > >     # unshare --ipc --mount --net qemu-system-x86_64 -qmp 
> > > > unix:/tmp/foo,server -vnc :1
> > > >     qemu-system-x86_64: -qmp unix:/tmp/foo,server: QEMU waiting for 
> > > > connection on: disconnected:unix:/tmp/foo,server
> > > > 
> > > > And in another shell I can still access the QMP socket from the 
> > > > original host
> > > > namespace
> > > 
> > > So that works because UNIX domains sockets are not restricted by network
> > > namespaces. But if you try to connect to the VNC server listening on TCP
> > > port 5901, it won't work.
> > > 
> > > > 
> > > >     # ./scripts/qmp/qmp-shell /tmp/foo
> > > >     Welcome to the QMP low-level shell!
> > > >     Connected to QEMU 2.9.1
> > > > 
> > > >     (QEMU) query-kvm
> > > >     {"return": {"enabled": false, "present": true}}
> > > > 
> > > > 
> > > > FWIW, even if that were not possible, you could still do it by wrapping 
> > > > the
> > > > qmp-shell in an 'nsenter' call. eg
> > > > 
> > > >     nsenter --target $QEMUPID --net ./scripts/qmp/qmp-shell /tmp/foo
> > > 
> > > I have a single process which connects to all the QEMUs' listening VNC
> > > sockets so I'm not sure that this would work.
> > 
> > Yes, it can still work - you simply need to use set() to temporarily
> > switch into QEMU's namespace, and then switch back again afterwards
> > 
> >    oldns = open("/proc/self/ns/net")
> >    newns = open("/proc/$PID-OF-QEMU/ns/net")
> >    setns(newns, CLONE_NEWNET)
> > 
> >    ...open connection to VNC...
> >    setns(oldns, CLONE_NEWNET)
> > 
> >    ...use connection to VNC...
> > 
> > The setns() call is thread-local, so you can safely use different
> > namespaces in each thread if you need to have concurrent comms with
> > many QEMUs.
> > 
> 
> Ah, I didn't realize that the namespace could be set locally for a thread.
> That's helpful, thanks!

Oh I should have mentioned that there's some caveats with joining some of
the other namespaces (mount + pid) - so be sure to check the setns() manpage
which describes the edge cases. eg changing pid namespace won't take effect
until you fork() a new child.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|