Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special
 files if caller has CAP_SYS_RESOURCE
To:     Vivek Goyal <vgoyal@redhat.com>
Cc:     "Dr. David Alan Gilbert" <dgilbert@redhat.com>, dwalsh@redhat.com,
        "Schaufler, Casey" <casey.schaufler@intel.com>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
        "virtio-fs@redhat.com" <virtio-fs@redhat.com>,
        "berrange@redhat.com" <berrange@redhat.com>,
        linux-security-module <linux-security-module@vger.kernel.org>,
        "selinux@vger.kernel.org" <selinux@vger.kernel.org>,
        Casey Schaufler <casey@schaufler-ca.com>
References: <20210625191229.1752531-1-vgoyal@redhat.com>
 <BN0PR11MB57275823CE05DED7BC755460FD069@BN0PR11MB5727.namprd11.prod.outlook.com>
 <20210628131708.GA1803896@redhat.com>
 <1b446468-dcf8-9e21-58d3-c032686eeee5@redhat.com>
 <5d8f033c-eba2-7a8b-f19a-1005bbb615ea@schaufler-ca.com>
 <YNn4p+Zn444Sc4V+@work-vm>
 <a13f2861-7786-09f4-99a8-f0a5216d0fb1@schaufler-ca.com>
 <YNrhQ9XfcHTtM6QA@work-vm>
 <e6f9ed0d-c101-01df-3dff-85c1b38f9714@schaufler-ca.com>
 <20210629152007.GC5231@redhat.com>
From:   Casey Schaufler <casey@schaufler-ca.com>
Message-ID: <78663f5c-d2fd-747a-48e3-0c5fd8b40332@schaufler-ca.com>
Date:   Tue, 29 Jun 2021 09:13:48 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210629152007.GC5231@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Content-Length: 2031
Precedence: bulk

On 6/29/2021 8:20 AM, Vivek Goyal wrote:
> On Tue, Jun 29, 2021 at 07:38:15AM -0700, Casey Schaufler wrote:
>
> [..]
>>>>>> User xattrs are less protected than security xattrs. You are expos=
ing the
>>>>>> security xattrs on the guest to the possible whims of a malicious,=
 unprivileged
>>>>>> actor on the host. All it needs is the right UID.
>>>>> Yep, we realise that; but when you're mainly interested in making s=
ure
>>>>> the guest can't attack the host, that's less worrying.
>>>> That's uncomfortable.
>>> Why exactly?
>> If a mechanism is designed with a known vulnerability you
>> fail your validation/evaluation efforts.
> We are working with the constraint that shared directory should not be
> accessible to unpriviliged users on host. And with that constraint, wha=
t
> you are referring to is not a vulnerability.

Sure, that's quite reasonable for your use case. It doesn't mean
that the vulnerability doesn't exist, it means you've mitigated it.=20


>> Your mechanism is
>> less general because other potential use cases may not be
>> as cavalier about the vulnerability.
> Prefixing xattrs with "user.virtiofsd" is just one of the options.
> virtiofsd has the capability to prefix "trusted.virtiofsd" as well.
> We have not chosen that because we don't want to give it CAP_SYS_ADMIN.=

>
> So other use cases which don't like prefixing "user.virtiofsd", can
> give CAP_SYS_ADMIN and work with it.
>
>> I think that you can
>> approach this differently, get a solution that does everything
>> you want, and avoid the known problem.
> What's the solution? Are you referring to using "trusted.*" instead? Bu=
t
> that has its own problem of giving CAP_SYS_ADMIN to virtiofsd.

I'm coming to the conclusion that xattr namespaces, analogous
to user namespaces, are the correct solution. They generalize
for multiple filesystem and LSM use cases. The use of namespaces
is well understood, especially in the container community. It
looks to me as if it would address your use case swimmingly.

>
> Thanks
> Vivek
>