Re: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE

[Daniel Walsh]

On 6/29/21 13:35, Vivek Goyal wrote:
> On Tue, Jun 29, 2021 at 09:13:48AM -0700, Casey Schaufler wrote:
> > 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 exposing 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 sure
> > > > > > > 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, what
> > > 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.
> >
> >
> > > > 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? But
> > > 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.
> Even if xattrs were namespaced, I am not sure it solves the issue
> of unpriviliged UID being able to modify security xattrs of file.
> If it happens to be correct UID, it should be able to spin up a
> user namespace and modify namespaced xattrs?
>
> Anyway, once namespaced xattrs are available, I will gladly make use
> of it. But that probably should not be a blocker for this patch.
>
> Vivek
All this conversation is great, and I look forward to a better solution, 
but if we go back to the patch, it was to fix an issue where the kernel 
is requiring CAP_SYS_ADMIN for writing user Xattrs on link files and 
other special files.

The documented reason for this is to prevent the users from using XATTRS 
to avoid quota.

The CAP_SYS_RESOURCE capability is denfined to allow processes with this 
capability to ignore quota.

This PR allows processes with CAP_SYS_RESOURCE to create user Xattrs.

To me this makes sense.

Is there any argument against this?