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