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?
