From: Vivek Goyal <vgoyal@redhat.com> To: Casey Schaufler <casey@schaufler-ca.com> Cc: 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>, "dgilbert@redhat.com" <dgilbert@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> Subject: Re: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Date: Mon, 28 Jun 2021 13:22:40 -0400 [thread overview] Message-ID: <20210628172240.GE1803896@redhat.com> (raw) In-Reply-To: <5d8f033c-eba2-7a8b-f19a-1005bbb615ea@schaufler-ca.com> On Mon, Jun 28, 2021 at 09:04:40AM -0700, Casey Schaufler wrote: [..] > > on a host without SELinux support but the VM has SELinux enabled, then virtiofsd needs CAP_SYS_ADMIN. It would be much more secure if it only needed CAP_SYS_RESOURCE. > > I don't know, so I'm asking. Does virtiofsd really get run with limited capabilities, > or does it get run as root like most system daemons? If it runs as root the argument > has no legs. It runs as root but we give it a set of minimum required capabilities by default and want to avoid giving it CAP_SYS_ADMIN. > > > If the host has SELinux enabled then it can run without CAP_SYS_ADMIN or CAP_SYS_RESOURCE, but it will only be allowed to write labels that the host system understands, any label not understood will be blocked. Not only this, but the label that is running virtiofsd pretty much has to run as unconfined, since it could be writing any SELinux label. > > You could fix that easily enough by teaching SELinux about the proper > use of CAP_MAC_ADMIN. Alas, I understand that there's no way that's > going to happen, and why it would be considered philosophically repugnant > in the SELinux community. > > > > > If virtiofsd is writing Userxattrs with CAP_SYS_RESOURCE, then we can run with a confined SELinux label only allowing it to sexattr on the content in the designated directory, make the container/vm much more secure. > > > 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. One of the security tenets of virtiofs is that this shared directory should be hidden from unprivliged users. Otherwise guest can drop setuid root binaries in shared directory and unprivliged user on host executes it and gets control of the host. So unpriviliged actor on host having access to these shared directory contents is wrong configuration. > > We have unused xattr namespaces. Would using the "trusted" namespace > work for your purposes? That requires giving CAP_SYS_ADMIN to daemon and one of the goals is to give as little capabilities as possible to virtiofsd. In fact people have been asking for the capablities to run virtiofsd unpriviliged as well as run inside a user namespace etc. Anyway, remapping LSM xattrs to "trusted.*" space should work as long as virtiofsd has CAP_SYS_ADMIN. Thanks Vivek
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com> To: Casey Schaufler <casey@schaufler-ca.com> Cc: "berrange@redhat.com" <berrange@redhat.com>, "selinux@vger.kernel.org" <selinux@vger.kernel.org>, "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> Subject: Re: [Virtio-fs] [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Date: Mon, 28 Jun 2021 13:22:40 -0400 [thread overview] Message-ID: <20210628172240.GE1803896@redhat.com> (raw) In-Reply-To: <5d8f033c-eba2-7a8b-f19a-1005bbb615ea@schaufler-ca.com> On Mon, Jun 28, 2021 at 09:04:40AM -0700, Casey Schaufler wrote: [..] > > on a host without SELinux support but the VM has SELinux enabled, then virtiofsd needs CAP_SYS_ADMIN. It would be much more secure if it only needed CAP_SYS_RESOURCE. > > I don't know, so I'm asking. Does virtiofsd really get run with limited capabilities, > or does it get run as root like most system daemons? If it runs as root the argument > has no legs. It runs as root but we give it a set of minimum required capabilities by default and want to avoid giving it CAP_SYS_ADMIN. > > > If the host has SELinux enabled then it can run without CAP_SYS_ADMIN or CAP_SYS_RESOURCE, but it will only be allowed to write labels that the host system understands, any label not understood will be blocked. Not only this, but the label that is running virtiofsd pretty much has to run as unconfined, since it could be writing any SELinux label. > > You could fix that easily enough by teaching SELinux about the proper > use of CAP_MAC_ADMIN. Alas, I understand that there's no way that's > going to happen, and why it would be considered philosophically repugnant > in the SELinux community. > > > > > If virtiofsd is writing Userxattrs with CAP_SYS_RESOURCE, then we can run with a confined SELinux label only allowing it to sexattr on the content in the designated directory, make the container/vm much more secure. > > > 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. One of the security tenets of virtiofs is that this shared directory should be hidden from unprivliged users. Otherwise guest can drop setuid root binaries in shared directory and unprivliged user on host executes it and gets control of the host. So unpriviliged actor on host having access to these shared directory contents is wrong configuration. > > We have unused xattr namespaces. Would using the "trusted" namespace > work for your purposes? That requires giving CAP_SYS_ADMIN to daemon and one of the goals is to give as little capabilities as possible to virtiofsd. In fact people have been asking for the capablities to run virtiofsd unpriviliged as well as run inside a user namespace etc. Anyway, remapping LSM xattrs to "trusted.*" space should work as long as virtiofsd has CAP_SYS_ADMIN. Thanks Vivek
next prev parent reply other threads:[~2021-06-28 17:22 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 2021-06-29 16:51 ` [Virtio-fs] " 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 [this message] 2021-06-28 17:22 ` 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=20210628172240.GE1803896@redhat.com \ --to=vgoyal@redhat.com \ --cc=berrange@redhat.com \ --cc=casey.schaufler@intel.com \ --cc=casey@schaufler-ca.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=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.