From mboxrd@z Thu Jan 1 00:00:00 1970 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=JzzUHiTMxm0ZNfihxxXdBiNsnYm4eMciVL+KVVEGWIE=; b=ZzeQvLfZ3tPP6pJbUBftSjpQP9UDskFXOrxbp6QHSxRaeF0cVMZNat2xUQD/LJkHrU 8WH1KoG8WfmNwzhysbVFLHpfwPykhhFvnQC6ZYcbKpKySFaRjupDUfeszyKfL6UE/JYB XAk/YlYmPjS8NikRqDEUbRTuBHvuDiEVo2jQNYU8UPfsYIx3AQIgwo3XV5cd5+vejR83 cnEEHLxXH95OVceEMLDS3SxgtSkW2PKo2MD4LyHEhV3W30jbRGfYdCe5H4FP+UkbYkR8 VIRoGXodf4XdYzRENBWAWgxSfpSL6IhXX0pLLP2WnvldH+vd8SuVL52FN4+Pzqw1VktL 0vTQ== References: <2234280.ElGaqSPkdT@subpop> <9W25UQ.OHKWX78P32DI3@sub-pop.net> <0KN5UQ.JVDR5LJRMJIQ3@sub-pop.net> <20210604134439.GB269481@redhat.com> From: "Harry G. Coin" Message-ID: <50f271ef-cc5e-e016-e9b6-8bb8ed5055dd@gmail.com> Date: Mon, 7 Jun 2021 09:37:03 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit 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: virtio-fs@redhat.com On 6/7/21 9:15 AM, Daniel P. Berrangé 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 >>>> 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=