From: Casey Schaufler <casey@schaufler-ca.com> To: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: Vivek Goyal <vgoyal@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> Subject: Re: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Date: Tue, 29 Jun 2021 09:51:47 -0700 [thread overview] Message-ID: <93e87539-29d1-2bed-9a79-ec378f6869b9@schaufler-ca.com> (raw) In-Reply-To: <YNtLtkkDMWye485A@work-vm> On 6/29/2021 9:35 AM, Dr. David Alan Gilbert wrote: > * Casey Schaufler (casey@schaufler-ca.com) 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 >>>
WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com> To: "Dr. David Alan Gilbert" <dgilbert@redhat.com> Cc: "berrange@redhat.com" <berrange@redhat.com>, "selinux@vger.kernel.org" <selinux@vger.kernel.org>, Casey Schaufler <casey@schaufler-ca.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "virtio-fs@redhat.com" <virtio-fs@redhat.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, linux-security-module <linux-security-module@vger.kernel.org>, "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>, "Schaufler, Casey" <casey.schaufler@intel.com>, Vivek Goyal <vgoyal@redhat.com> Subject: Re: [Virtio-fs] [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Date: Tue, 29 Jun 2021 09:51:47 -0700 [thread overview] Message-ID: <93e87539-29d1-2bed-9a79-ec378f6869b9@schaufler-ca.com> (raw) In-Reply-To: <YNtLtkkDMWye485A@work-vm> On 6/29/2021 9:35 AM, Dr. David Alan Gilbert wrote: > * Casey Schaufler (casey@schaufler-ca.com) 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 >>>
next prev parent reply other threads:[~2021-06-29 16:51 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-25 19:12 [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Vivek Goyal 2021-06-25 19:12 ` [Virtio-fs] " Vivek Goyal 2021-06-25 19:12 ` [PATCH 1/1] xattr: Allow user.* xattr on symlink/special files with CAP_SYS_RESOURCE Vivek Goyal 2021-06-25 19:12 ` [Virtio-fs] " Vivek Goyal 2021-06-28 12:33 ` Christian Brauner 2021-06-28 12:33 ` [Virtio-fs] " Christian Brauner 2021-06-28 15:00 ` Vivek Goyal 2021-06-28 15:00 ` [Virtio-fs] " Vivek Goyal 2021-06-29 3:13 ` [xattr] 8d8cd767b6: ltp.setxattr02.fail kernel test robot 2021-06-29 3:13 ` [Virtio-fs] " kernel test robot 2021-06-29 3:13 ` kernel test robot 2021-06-29 3:13 ` [LTP] " kernel test robot 2021-06-29 12:59 ` Vivek Goyal 2021-06-29 12:59 ` [Virtio-fs] " Vivek Goyal 2021-06-29 12:59 ` Vivek Goyal 2021-06-29 12:59 ` [LTP] " Vivek Goyal 2021-06-25 21:49 ` [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Schaufler, Casey 2021-06-25 21:49 ` [Virtio-fs] " Schaufler, Casey 2021-06-28 11:58 ` Dr. David Alan Gilbert 2021-06-28 11:58 ` [Virtio-fs] " Dr. David Alan Gilbert 2021-06-28 13:17 ` Vivek Goyal 2021-06-28 13:17 ` [Virtio-fs] " Vivek Goyal 2021-06-28 13:36 ` Daniel Walsh 2021-06-28 13:36 ` [Virtio-fs] " Daniel Walsh 2021-06-28 16:04 ` Casey Schaufler 2021-06-28 16:04 ` [Virtio-fs] " Casey Schaufler 2021-06-28 16:28 ` Dr. David Alan Gilbert 2021-06-28 16:28 ` [Virtio-fs] " Dr. David Alan Gilbert 2021-06-28 17:41 ` Casey Schaufler 2021-06-28 17:41 ` [Virtio-fs] " Casey Schaufler 2021-06-29 9:00 ` Dr. David Alan Gilbert 2021-06-29 9:00 ` [Virtio-fs] " Dr. David Alan Gilbert 2021-06-29 14:38 ` Casey Schaufler 2021-06-29 14:38 ` [Virtio-fs] " Casey Schaufler 2021-06-29 15:20 ` Vivek Goyal 2021-06-29 15:20 ` [Virtio-fs] " Vivek Goyal 2021-06-29 16:13 ` Casey Schaufler 2021-06-29 16:13 ` [Virtio-fs] " Casey Schaufler 2021-06-29 16:35 ` Dr. David Alan Gilbert 2021-06-29 16:35 ` [Virtio-fs] " Dr. David Alan Gilbert 2021-06-29 16:51 ` Casey Schaufler [this message] 2021-06-29 16:51 ` Casey Schaufler 2021-06-29 17:35 ` Vivek Goyal 2021-06-29 17:35 ` [Virtio-fs] " Vivek Goyal 2021-06-29 20:28 ` Daniel Walsh 2021-06-29 20:28 ` [Virtio-fs] " Daniel Walsh 2021-06-30 4:12 ` Theodore Ts'o 2021-06-30 4:12 ` [Virtio-fs] " Theodore Ts'o 2021-06-30 8:07 ` Dr. David Alan Gilbert 2021-06-30 8:07 ` [Virtio-fs] " Dr. David Alan Gilbert 2021-06-30 14:47 ` Theodore Ts'o 2021-06-30 14:47 ` [Virtio-fs] " Theodore Ts'o 2021-06-30 15:01 ` Dr. David Alan Gilbert 2021-06-30 15:01 ` [Virtio-fs] " Dr. David Alan Gilbert 2021-06-30 19:59 ` Theodore Ts'o 2021-06-30 19:59 ` [Virtio-fs] " Theodore Ts'o 2021-06-30 20:32 ` Vivek Goyal 2021-06-30 20:32 ` [Virtio-fs] " Vivek Goyal 2021-07-01 8:48 ` Dr. David Alan Gilbert 2021-07-01 8:48 ` [Virtio-fs] " Dr. David Alan Gilbert 2021-07-01 12:21 ` Vivek Goyal 2021-07-01 12:21 ` [Virtio-fs] " Vivek Goyal 2021-07-01 13:10 ` Vivek Goyal 2021-07-01 13:10 ` [Virtio-fs] " Vivek Goyal 2021-07-01 16:58 ` Casey Schaufler 2021-07-01 16:58 ` [Virtio-fs] " Casey Schaufler 2021-06-30 16:09 ` Vivek Goyal 2021-06-30 16:09 ` [Virtio-fs] " Vivek Goyal 2021-06-30 14:27 ` Vivek Goyal 2021-06-30 14:27 ` [Virtio-fs] " Vivek Goyal 2021-06-29 16:25 ` Theodore Ts'o 2021-06-29 16:25 ` [Virtio-fs] " Theodore Ts'o 2021-06-28 17:22 ` Vivek Goyal 2021-06-28 17:22 ` [Virtio-fs] " Vivek Goyal 2021-06-28 18:55 ` Daniel Walsh 2021-06-28 18:55 ` [Virtio-fs] " Daniel Walsh
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=93e87539-29d1-2bed-9a79-ec378f6869b9@schaufler-ca.com \ --to=casey@schaufler-ca.com \ --cc=berrange@redhat.com \ --cc=casey.schaufler@intel.com \ --cc=dgilbert@redhat.com \ --cc=dwalsh@redhat.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=selinux@vger.kernel.org \ --cc=vgoyal@redhat.com \ --cc=viro@zeniv.linux.org.uk \ --cc=virtio-fs@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.