From mboxrd@z Thu Jan 1 00:00:00 1970 References: <2234280.ElGaqSPkdT@subpop> <9W25UQ.OHKWX78P32DI3@sub-pop.net> <0KN5UQ.JVDR5LJRMJIQ3@sub-pop.net> <20210604134439.GB269481@redhat.com> From: Daniel Walsh Message-ID: <15e860ba-5ea3-90d6-eccf-6003f6874bc7@redhat.com> Date: Mon, 7 Jun 2021 09:01:08 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [Virtio-fs] virtiofs mounted filesystems & SELinux Reply-To: dwalsh@redhat.com List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , Vivek Goyal Cc: virtio-fs-list , libvirt-users@redhat.com, Link Dupont 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 >>> 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 > >> Another option is, can we use a single label for whole of the >> virtiofs (using context=