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(a)sub-pop.net>
> > > 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.
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
--
|: