From mboxrd@z Thu Jan 1 00:00:00 1970 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sub-pop.net ; s=mythic-beasts-k1; h=To:Subject:From:Date; bh=FrHj+OATBRjDv8uDkdX1QohJGCBX9qQVJcv1uklAB8Y=; b=wMiSBnoBd266lOvpSmcl87RZHh zU/IeJBIk7ERyS8sXLMpnbavbNuON5+hq8tDbCGiXdiHZLnX/uxwkvCL/XiGFMQauAoCL1ZPBeI96 iPxio0ZmyrWFuhhf3eGchqfzb+GuzbYElxVfwH8mAXCWHA6/u3YI0XoG/MoeMPqjhSQwYNobtvZsI i4LbqhXvF7skToR/AIszPPZoYSTji/Aji+XmV1WXmmLv5aChjj7JigjiPkkuZ7oPqxZGTjVsSlGBi x6tP5eDrrNYc1/woTfuKFF5QUIKBEG/FkP0a3afa54YJAI72+21Lciyn+Nnv+g+TSWtHgDe8inmRa xy/Ipe2A== Date: Mon, 07 Jun 2021 10:05:09 -0400 From: Link Dupont Message-Id: In-Reply-To: <15e860ba-5ea3-90d6-eccf-6003f6874bc7@redhat.com> References: <2234280.ElGaqSPkdT@subpop> <9W25UQ.OHKWX78P32DI3@sub-pop.net> <0KN5UQ.JVDR5LJRMJIQ3@sub-pop.net> <20210604134439.GB269481@redhat.com> <15e860ba-5ea3-90d6-eccf-6003f6874bc7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: quoted-printable 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: dwalsh@redhat.com Cc: virtio-fs-list , libvirt-users@redhat.com, "Daniel P. =?iso-8859-1?q?Berrang=E9?=" , Vivek Goyal On Mon, Jun 7 2021 at 09:01:08 AM -0400, Daniel Walsh=20 wrote: > On 6/4/21 09:59, 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=20 >>>> >>>> wrote: >>>>> reproducible scenarios >>>> Alright. I reran my tests with a CentOS 8 guest. On CentOS 8 (with=20 >>>> a >>>> virtiofs filesystem and with xattr on), the type of files in the=20 >>>> mounted >>>> hierarchy are unlabeled_t. I can work around that by switching=20 >>>> SELinux in >>>> the guest to permissive or disabled. >>> cc Dan Walsh. I was discussing this with Dan Walsh yesterday in=20 >>> general. >>>=20 >>> In general, if we want to enable SELinux both on host and guest,=20 >>> 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. >>=20 >>=20 >>> 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=20 >>> 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. >>=20 >>> https://github.com/qemu/qemu/blob/master/docs/tools/virtiofsd.rst >>>=20 >>> 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. >>=20 >> 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 >>=20 >>> Another option is, can we use a single label for whole of the >>> virtiofs (using context=3D