On 01/21/21 16:52, Alex Xu wrote: > 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.
Awesome, this is the best answer I could possibly get. Thank you! Laszlo
