On Fri, Jun 04, 2021 at 10:43:13AM -0400, Vivek Goyal wrote: > On Fri, Jun 04, 2021 at 02:59:29PM +0100, 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> > > > > wrote: > > > > > 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 > > > policies. > > > > 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 > > > user.virtiofs.security.selinux 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. > > > > > https://github.com/qemu/qemu/blob/master/docs/tools/virtiofsd.rst > > > > > > 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 > > > files. > > > > 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 > > Per mount point auto relabel seems interesting. Will it relabel > everytime virtiofs export shows up. Or it will intelligence to > figure out exported fs is already labeled (say from previous boot) > and no need to relabel again. Normal behaviour with the existing global /.autorelabel is that selinux deletes the file once the relabel is complete, so it is a one-time thing. Essentially anytime you need to force[1] a one-time only relabel you just do "touch /.autorelabel && reboot" DanW does however recommend that you configure your system such that the labels are always correct and thus don't need the global relabel. https://danwalsh.livejournal.com/38157.html None the less I think the virtiofs situation is slightly different and justifies a way to force relabel, provided it can be scoped to just that one filesystem mount. 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 :|