Re: [Virtio-fs] virtiofs mounted filesystems & SELinux

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


On Mon, Jun 7 2021 at 09:01:08 AM -0400, Daniel Walsh <dwalsh@xxxxxxxxxx> wrote:
On 6/4/21 09:59, Daniel P. Berrangé wrote:
On Fri, Jun 04, 2021 at 09:44:39AM -0400, Vivek Goyal wrote:
On Thu, Jun 03, 2021 at 10:14:24PM -0400, Link Dupont wrote:
On Thu, Jun 3 2021 at 08:56:46 PM -0400, Link Dupont <link@xxxxxxxxxxx>
  reproducible scenarios
Alright. I reran my tests with a CentOS 8 guest. On CentOS 8 (with a virtiofs filesystem and with xattr on), the type of files in the mounted hierarchy are unlabeled_t. I can work around that by switching SELinux in
the guest to permissive or disabled.
cc Dan Walsh. I was discussing this with Dan Walsh yesterday in general.

In general, if we want to enable SELinux both on host and guest, then
both host and guest should have same SELinux policy. Otherwise there
will be lot of different kind of conflicts because both host and
guest will try to work with same selinux label. I guess that in
practice this will be very hard to achieve as people will run
different host and guest flavors and these might have different
Yeah, I think there's little to no chance of people keeping the
same SELinux policy in host/guest, except in very tightly controlled
narrow use cases where the host admin exerts direct control over
the precise guest config.

So another option is to rename selinux xattr in virtiofs so that
any selinux xattr coming from guest is saved as xattr on host. That way host and guest
can have their separate labels without interfering with each other.
David Gilbert already has added support for this. I can't remember
the exact syntax but you can figure it out from documentation here
in xattr remappig section.
For general purpose virt usage, I think remapping in some way is
likely to be needed as the default strategy.

But I have question with selinux xattr remapping. What will happen
to initial labels when fs is exported. I mean until and unless
some process in guest labels all the exported files, they all
with either be unlabeled or pick some generic label for all the
I'd say you need some mechanism to force a re-label inside the
guest. Normally a relabel will be done in /.autorelabel file
is present, or in certain other scenarios like selinux policy
RPM updates.

We wouldn't want to force a relabel neccesarily for the entire
FS if we're just hotplugging a new virtiofs export though. So
perhaps there's scope for supporting usage of a per-mount
point relabel trigger. eg Host creates $VIRTIOFS-ROOT/.autorelabel
and whenever the guest sees a new virtiofs export arriving, it
can look for $VIRTIOFS-MOUNT-POINT/.autorelabel

Another option is, can we use a single label for whole of the
virtiofs (using context=<label>) option in guest. That way nothing
is saved in files as such. But this means that processes in guest
can't have different selinux labels on different virtiofs dir/files.
Forcing a single label for the entire export is passable as a
fallback plan. This is what people have done for years with
NFS v3 mounts. It has annoying usage limitations though, so
if at all possible remapping is a preferrable approach.

Dan, what do you think?


With a CentOS 7 guest, things get less usable. I digested this to a
reproducible scenario.

Build a disk image with `virt-builder`, configuring the CentOS Plus kernel
to get 9p support.

virt-builder centos-7.8 \
--root-password password:centos \
--output centos-7.8.qcow2 \
--install yum-utils \
--run-command 'yum-config-manager --enable centosplus' \
--run-command 'sed -ie "s/DEFAULTKERNEL=kernel/DEFAULTKERNEL=kernel-plus/"
/etc/sysconfig/kernel' \
--append-line '/etc/dracut.conf.d/virtio.conf:add_drivers+="virtio_scsi
virtio_pci virtio_console"' \
--append-line '/etc/modules-load.d/9pnet_virtio.conf:9pnet_virtio' \
--install kernel-plus \
--append-line '/etc/fstab:home /home 9p trans=virtio,version=9p2000.L 0 0'

Install the volume into the `default` pool.

sudo install -m644 centos-7.8.qcow2 /var/lib/libvirt/images

Next, define a domain using the disk image (using `virt-install` here for
"easy mode").

virt-install \
--import \
--os-variant centos7.0 \
--name centos \
--ram 2048 \
--disk path=/var/lib/libvirt/images/centos-7.8.qcow2 \
--memorybacking access.mode=shared \
--filesystem source=/home,target=home,accessmode=passthrough \
--autoconsole none

Now with SELinux enforcing, I cannot list the contents of the directories in
the mounted hierarchy.

[root@localhost ~]# ls -lZ /home/link
ls: cannot open directory /home/link: Permission denied

Virtio-fs mailing list


The separate XAttr support would also allow virtiofsd to work with labels inside of the container when the virtiofsd is confined on the host.

I would guess/hope virtiofsd on the host will be confined and only able to write certain labels like container_file_t or svirt_image_t. If you want to allow virt file systems within the "VM" to be able to set labels, these labels will have to be something other then SELinux labels on the host, or SELinux will prevent them from being set.

I don't think the guest needs to be able to set labels on the virtiofs filesystems; as long as it can read labels that grant read and write access as the guest user, I'd call it a success. The way I use this feature, I'm treating my host filesystem as the "source", and really only mounting it into the guest as a zero-delay synchronization. (I previously did this using sync solutions like rsync or lsyncd, but those have a slight delay before files sync over.)

If the labels as seen by the guest allow for reading and writing files from the guest to the host filesystem, I'd be happy. Doing any relabeling from the host is totally fine.

[Index of Archives]     [Virt Tools]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux