qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] Disconecting /dev/nbdX leaves stale partitions and devi


From: Stefan Hajnoczi
Subject: Re: [Qemu-block] Disconecting /dev/nbdX leaves stale partitions and device
Date: Wed, 18 Jul 2018 14:18:33 +0100
User-agent: Mutt/1.10.0 (2018-05-17)

On Wed, Jul 11, 2018 at 08:28:38PM +0300, Nir Soffer wrote:
> On Wed, Jul 11, 2018 at 3:40 PM Stefan Hajnoczi <address@hidden> wrote:
> 
> > On Thu, Jul 05, 2018 at 02:10:58AM +0300, Nir Soffer wrote:
> >
> > CCing Eric and Paolo, who maintain QEMU's NBD code.
> >
> > > I'm trying to access a qcow2 image via /dev/nbdX device.
> >
> > Untrusted disk images should not be attached to the host using qemu-nbd
> > (or loopback devices) for security reasons.  If you hit this bug during
> > development or ad-hoc qemu-nbd usage, then that's fine.  But I just
> > wanted to post a reminder that production use cases should not use this
> > feature when dealing with untrusted disk images.
> >
> 
> Thanks for the warning. We intend to use it with oVirt disks, which are
> generally
> created by qemu. But these disks may also be uploaded by the oVirt
> administrator
> or by a backup application. They can also be modified by anything running on
> a hypervisor, since oVirt storage is available on all hypervisors. Finally
> it can be
> corrupted on storage.
> 
> Basically anything we feed to qemu or qemu-img may be fed to qemu-nbd.
> We assume that qemu-nbd is robust to handle broken images.

qemu-nbd doesn't post a security risk since it does not interpret the
contents of the disk.  (Assuming oVirt explicitly specifies the image
file format using qemu-nbd --format=FORMAT.  This is important, too.)

The security risk is attaching an untrusted disk to the host via
/dev/nbdX.  The Linux developers do not consider this secure.  For
example, mounting a filesystem from an untrusted disk could compromise
the host.  There are other vectors like partition table probing or
userspace activity in response to the disk add uevent (udev).

This is why libguestfs always accesses disks from an appliance VM
instead of attaching them directly on the host.

> Without this we
> would not be able to provide guest data for incremental backup or other
> purposes.

You can provide access to the data without attaching it as a host block
device (/dev/nbdX).

Drop the -c argument and use --socket=PATH (UNIX domain socket) or
--port=TCP_PORT (TCP listen socket) instead.  Now you have an NBD server
that accesses the image file from userspace (without attaching a host
block device).  This avoids the security issues with host block devices.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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