From: "J. Bruce Fields" <bfields@redhat.com> To: Stephen Smalley <sds@tycho.nsa.gov> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-security-module@vger.kernel.org, James Morris <james.l.morris@oracle.com>, selinux@tycho.nsa.gov Subject: Re: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts Date: Thu, 30 Mar 2017 13:41:47 -0400 [thread overview] Message-ID: <20170330174147.GA11004@parsley.fieldses.org> (raw) In-Reply-To: <1490894827.2099.2.camel@tycho.nsa.gov> On Thu, Mar 30, 2017 at 01:27:07PM -0400, Stephen Smalley wrote: > On Thu, 2017-03-30 at 09:49 +0200, Tomeu Vizoso wrote: > > On 29 March 2017 at 23:34, J. Bruce Fields <bfields@redhat.com> > > wrote: > > > On Wed, Mar 29, 2017 at 05:27:23PM +0200, Tomeu Vizoso wrote: > > > > Labelling of files in a NFSv4.2 currently fails with ENOTSUPP > > > > because > > > > the mount point doesn't have SBLABEL_MNT. > > > > > > > > Add specific condition for NFS4 filesystems so it gets correctly > > > > labeled. > > > > > > Huh. Looking at the code, I think this is meant to be handled by > > > the > > > SECURITY_FS_USE_NATIVE case--there was a similar failure fixed some > > > time > > > ago by 9fc2b4b436cf. What kernel are you seeing this on? Is it a > > > recent regression (in which case, what's the latest kernel that > > > worked > > > for you)? > > > > I have seen this on 4.11-rc4, but I never tried to get this working > > before. > > > > I will try to find time to see why SECURITY_FS_USE_NATIVE isn't > > working here. > > Does your exports file specify the "security_label" option, e.g. > /path/to/dir example.com(rw,security_label) Oops, right, that should have been the first thing I asked about.... > It appears that with recent kernels that is now required; otherwise, > the mount defaults to not enabling native labeling and all of the files > are treated as having a single, fixed label defined by the client > policy (and hence setxattr is not supported). This was kernel commit > 32ddd944a056c786f6acdd95ed29e994adc613a2. I don't recall seeing any > discussion of this on selinux list. I understand the rationale, but it > seems like a user-visible regression It is. I also want to keep new protocol upgrades free of user regressions, which the 4.1->4.2 upgrade is in most cases if we turn on security labeling by default. So I was stuck choosing between two regresisons, and figured 4.2 user depending on security labeling was still the much rarer case. So I'd like to keep security labeling off by default, but if there's anything I can do to smooth the transition obviously that's good. > and at the very least, it seems odd that they didn't just use > "seclabel" as the kernel does in /proc/mounts to signify a filesystem > that supports security labeling by userspace. I see logic in sb_finish_set_opts() that sets SBLABEL_MNT in the selinux_is_sblabel_mnt() case. Doesn't that mean "seclabel" shows up in /proc/mounts when we nfs sets SECURITY_LSM_NATIVE_LABELS? I may not understand your comment, I'm pretty unfamiliar with this area. --b.
WARNING: multiple messages have this Message-ID (diff)
From: bfields@redhat.com (J. Bruce Fields) To: linux-security-module@vger.kernel.org Subject: [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts Date: Thu, 30 Mar 2017 13:41:47 -0400 [thread overview] Message-ID: <20170330174147.GA11004@parsley.fieldses.org> (raw) In-Reply-To: <1490894827.2099.2.camel@tycho.nsa.gov> On Thu, Mar 30, 2017 at 01:27:07PM -0400, Stephen Smalley wrote: > On Thu, 2017-03-30 at 09:49 +0200, Tomeu Vizoso wrote: > > On 29 March 2017 at 23:34, J. Bruce Fields <bfields@redhat.com> > > wrote: > > > On Wed, Mar 29, 2017 at 05:27:23PM +0200, Tomeu Vizoso wrote: > > > > Labelling of files in a NFSv4.2 currently fails with ENOTSUPP > > > > because > > > > the mount point doesn't have SBLABEL_MNT. > > > > > > > > Add specific condition for NFS4 filesystems so it gets correctly > > > > labeled. > > > > > > Huh.??Looking at the code, I think this is meant to be handled by > > > the > > > SECURITY_FS_USE_NATIVE case--there was a similar failure fixed some > > > time > > > ago by 9fc2b4b436cf.??What kernel are you seeing this on???Is it a > > > recent regression (in which case, what's the latest kernel that > > > worked > > > for you)? > > > > I have seen this on 4.11-rc4, but I never tried to get this working > > before. > > > > I will try to find time to see why SECURITY_FS_USE_NATIVE isn't > > working here. > > Does your exports file specify the "security_label" option, e.g. > /path/to/dir example.com(rw,security_label) Oops, right, that should have been the first thing I asked about.... > It appears that with recent kernels that is now required; otherwise, > the mount defaults to not enabling native labeling and all of the files > are treated as having a single, fixed label defined by the client > policy (and hence setxattr is not supported). This was kernel commit > 32ddd944a056c786f6acdd95ed29e994adc613a2. I don't recall seeing any > discussion of this on selinux list. I understand the rationale, but it > seems like a user-visible regression It is. I also want to keep new protocol upgrades free of user regressions, which the 4.1->4.2 upgrade is in most cases if we turn on security labeling by default. So I was stuck choosing between two regresisons, and figured 4.2 user depending on security labeling was still the much rarer case. So I'd like to keep security labeling off by default, but if there's anything I can do to smooth the transition obviously that's good. > and at the very least, it seems odd that they didn't just use > "seclabel" as the kernel does in /proc/mounts to signify a filesystem > that supports security labeling by userspace. I see logic in sb_finish_set_opts() that sets SBLABEL_MNT in the selinux_is_sblabel_mnt() case. Doesn't that mean "seclabel" shows up in /proc/mounts when we nfs sets SECURITY_LSM_NATIVE_LABELS? I may not understand your comment, I'm pretty unfamiliar with this area. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-03-30 17:41 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-29 15:27 [PATCH] selinux: Fix SBLABEL_MNT for NFS mounts Tomeu Vizoso 2017-03-29 15:27 ` Tomeu Vizoso 2017-03-29 21:34 ` J. Bruce Fields 2017-03-29 21:34 ` J. Bruce Fields 2017-03-30 7:49 ` Tomeu Vizoso 2017-03-30 7:49 ` Tomeu Vizoso 2017-03-30 17:27 ` Stephen Smalley 2017-03-30 17:27 ` Stephen Smalley 2017-03-30 17:41 ` J. Bruce Fields [this message] 2017-03-30 17:41 ` J. Bruce Fields 2017-03-30 17:52 ` Stephen Smalley 2017-03-30 17:52 ` Stephen Smalley 2017-04-04 23:26 ` J. Bruce Fields 2017-04-04 23:26 ` J. Bruce Fields 2017-05-25 21:07 ` [PATCH RFC 0/2] Fix setting of security labels over NFSv4.2 Scott Mayhew 2017-05-25 21:07 ` [PATCH RFC 1/2] selinux: allow SECURITY_LSM_NATIVE_LABELS to be set on an already initialized superblock Scott Mayhew 2017-05-25 21:07 ` [PATCH RFC 2/2] nfs: update labeling behavior on a superblock when submounting Scott Mayhew 2017-05-26 14:24 ` Stephen Smalley 2017-05-26 15:28 ` Scott Mayhew 2017-05-26 15:42 ` Stephen Smalley 2017-06-01 14:46 ` [PATCH] security/selinux: allow security_sb_clone_mnt_opts to enable/disable native labeling behavior Scott Mayhew 2017-06-01 14:55 ` Scott Mayhew 2017-06-01 18:08 ` Stephen Smalley 2017-06-01 18:48 ` Stephen Smalley 2017-06-01 19:40 ` Scott Mayhew 2017-06-01 18:30 ` Stephen Smalley 2017-06-01 19:42 ` Scott Mayhew 2017-06-01 20:59 ` [PATCH v2] " Scott Mayhew 2017-06-02 12:55 ` Stephen Smalley 2017-06-02 13:09 ` Scott Mayhew 2017-06-05 15:45 ` [PATCH v3] " Scott Mayhew 2017-06-05 15:55 ` Scott Mayhew 2017-06-05 19:53 ` Stephen Smalley 2017-06-05 21:21 ` Paul Moore 2017-06-06 0:46 ` J . Bruce Fields 2017-06-09 20:24 ` Paul Moore 2017-05-30 14:38 ` [PATCH RFC 2/2] nfs: update labeling behavior on a superblock when submounting Stephen Smalley 2017-05-30 19:40 ` J . Bruce Fields 2017-05-30 19:52 ` Stephen Smalley 2017-05-26 14:48 ` [PATCH RFC 0/2] Fix setting of security labels over NFSv4.2 Stephen Smalley 2017-05-26 15:17 ` J . Bruce Fields 2017-05-26 15:18 ` J . Bruce Fields 2017-05-26 15:30 ` Scott Mayhew
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=20170330174147.GA11004@parsley.fieldses.org \ --to=bfields@redhat.com \ --cc=james.l.morris@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=sds@tycho.nsa.gov \ --cc=selinux@tycho.nsa.gov \ --cc=tomeu.vizoso@collabora.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.