Re: [PATCH] virtiofsd: prevent opening of special files (CVE-2020-35517)

[alex--- via <qemu-devel@nongnu.org>]

Excerpts from Laszlo Ersek's message of January 21, 2021 10:32 am:
> Assuming a benign / trusted guest, is there going to be an override for
> this?
> 
> Asked differently -- if we don't want to set up a separate block device
> on the host, to contain the filesystem that is mounted as the shared
> directory, can unionfs (?) / overlayfs be used to re-mount an existent
> host-side directory as the shared directory, but with
> "noexec,nosuid,nodev" *bolted-on*?
> 
> If people have to create separate block devices (on the host side) for
> innocent use cases such as running tests in a trusted guest, that's not
> going to qualify as "usability progress" relative to having a qcow2 (or
> raw) image file.
> 
> "nodev,nosuid" is kind of a no-brainer for any host-side *data* volume
> anyway (such as the one underlying "/home", even), so I don't see those
> options as a challenge. But "noexec" is different.
> 
> Thanks,
> Laszlo

On Linux, there are two types of mount options: per-superblock, and 
per-point. Most filesystem-specific options are per-superblock, and 
apply to all mounts of that device. noexec, nosuid, and nodev are 
per-mount options, and apply individually to each mount, bind or 
otherwise, of a given device. Bind mounts copy the parent per-mount 
options, but can be individually altered. Note also that it is not 
required to create a new location for a bind mount.

For example, invoking:

mount --bind -o noexec,nosuid,nodev /var/lib/vms/source1 /var/lib/vms/source1

would effectively secure a source directory. This can also be inserted 
in /etc/fstab, such as:

/var/lib/vms/source1 /var/lib/vms/source1 none bind,noexec,nosuid,nodev 0 0

Note that, as explained in Stefan's initial email, this hides any 
submounts below source. Each of those must be individually protected, 
either by initially mounting with the security options or by creating a 
new bind mount as above. Although these cases should be infrequent, they 
are common enough that Stefan and I think that they should be supported, 
or at the very least not silently behave in unexpected or insecure ways.

Additionally, while it's possible to use overlayfs for this purpose, 
it's overkill, and as far as I understand, doesn't solve the problem of 
hiding sub-mounts.

Regards,
Alex.