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: Tue, 4 Apr 2017 19:26:47 -0400 [thread overview]
Message-ID: <20170404232646.GB24146@parsley.fieldses.org> (raw)
In-Reply-To: <1490896334.2099.4.camel@tycho.nsa.gov>
On Thu, Mar 30, 2017 at 01:52:14PM -0400, Stephen Smalley wrote:
> On Thu, 2017-03-30 at 13:41 -0400, J. Bruce Fields wrote:
> > 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.
>
> Yes, I understand - wish though that it could have been communicated
> better, e.g. on selinux list (unless I just missed it somehow).
No, I didn't think of it, apologies, I agree that would have been
smarter.
> > > 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.
>
> Correct, I just meant it seems potentially confusing to users to use
> "security_label" in exports when we show it as "seclabel" in
> /proc/mounts. I know, they are totally different namespaces (in the
> conventional sense), but consistency might have been more user-
> friendly.
Oh, got it.
We've had problems when NFS client mount and server export options are
spelled the same but have subtle differences in semantics (I'm thinking
of "async"). But maybe that wouldn't have been an issue here.
--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: Tue, 4 Apr 2017 19:26:47 -0400 [thread overview]
Message-ID: <20170404232646.GB24146@parsley.fieldses.org> (raw)
In-Reply-To: <1490896334.2099.4.camel@tycho.nsa.gov>
On Thu, Mar 30, 2017 at 01:52:14PM -0400, Stephen Smalley wrote:
> On Thu, 2017-03-30 at 13:41 -0400, J. Bruce Fields wrote:
> > 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.
>
> Yes, I understand - wish though that it could have been communicated
> better, e.g. on selinux list (unless I just missed it somehow).
No, I didn't think of it, apologies, I agree that would have been
smarter.
> > > 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.
>
> Correct, I just meant it seems potentially confusing to users to use
> "security_label" in exports when we show it as "seclabel" in
> /proc/mounts. I know, they are totally different namespaces (in the
> conventional sense), but consistency might have been more user-
> friendly.
Oh, got it.
We've had problems when NFS client mount and server export options are
spelled the same but have subtle differences in semantics (I'm thinking
of "async"). But maybe that wouldn't have been an issue here.
--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-04-04 23:26 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
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 [this message]
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=20170404232646.GB24146@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: link
Be 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.