On 6/29/2021 9:35 AM, Dr. David Alan Gilbert wrote: > * Casey Schaufler (casey@xxxxxxxxxxxxxxxx) 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. > Yeh; although the details of getting the semantics right is tricky; > in particular, the stuff which clears capabilitiies/setuid/etc on writes > - should it clear xattrs that represent capabilities? If the host > performs a write, should it clear mapped xattrs capabilities? If the > namespace performs a write should it clear just the mapped ones or the > host ones as well? Our virtiofsd code performs acrobatics to make > sure they get cleared on write that are painful. Dealing with tricky semantics is the difference between a feature and a hack. Doing so in a way that other people can take advantage of the feature is the hallmark of a feature well done. > > Dave > >>> Thanks >>> Vivek >>>
