From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 8 Jun 2021 16:55:03 +0100 From: "Dr. David Alan Gilbert" Message-ID: References: <2234280.ElGaqSPkdT@subpop> <9W25UQ.OHKWX78P32DI3@sub-pop.net> <0KN5UQ.JVDR5LJRMJIQ3@sub-pop.net> <20210604134439.GB269481@redhat.com> <50f271ef-cc5e-e016-e9b6-8bb8ed5055dd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <50f271ef-cc5e-e016-e9b6-8bb8ed5055dd@gmail.com> Subject: Re: [Virtio-fs] virtiofs mounted filesystems & SELinux List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Harry G. Coin" Cc: virtio-fs@redhat.com * Harry G. Coin (hgcoin@gmail.com) wrote: >=20 > On 6/7/21 9:15 AM, Daniel P. Berrang=E9 wrote: > > On Fri, Jun 04, 2021 at 02:59:29PM +0100, Daniel P. Berrang=E9 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 mou= nted > >>>> hierarchy are unlabeled_t. I can work around that by switching SELin= ux in > >>>> the guest to permissive or disabled. > >>> cc Dan Walsh. I was discussing this with Dan Walsh yesterday in gener= al. > >>> > >>> 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=3D