[PATCH] selinux: fix setting of security labels on NFS

[PATCH] selinux: fix setting of security labels on NFS

[J. Bruce Fields]

From: "J. Bruce Fields" <bfields@redhat.com>

Before calling into the filesystem, vfs_setxattr calls
security_inode_setxattr, which ends up calling selinux_inode_setxattr in
our case.  That returns -EOPNOTSUPP whenever SBLABEL_MNT is not set.
SBLABEL_MNT was supposed to be set by sb_finish_set_opts, which sets it
only if selinux_is_sblabel_mnt returns true.

The selinux_is_sblabel_mnt logic was broken by eadcabc697e9 "SELinux: do
all flags twiddling in one place", which didn't take into the account
the SECURITY_FS_USE_NATIVE behavior that had been introduced for nfs
with eb9ae686507b "SELinux: Add new labeling type native labels".

This caused setxattr's of security labels over NFSv4.2 to fail.

Cc: stable@kernel.org
Cc: Eric Paris <eparis@redhat.com>
Cc: David Quigley <dpquigl@davequigley.com>
Reported-by: Richard Chan <rc556677@outlook.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
 security/selinux/hooks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e8a060bd9677..171fb30e4b99 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -403,6 +403,7 @@ static int selinux_is_sblabel_mnt(struct super_block *sb)
 	return sbsec->behavior == SECURITY_FS_USE_XATTR ||
 		sbsec->behavior == SECURITY_FS_USE_TRANS ||
 		sbsec->behavior == SECURITY_FS_USE_TASK ||
+		sbsec->behavior == SECURITY_FS_USE_NATIVE ||
 		/* Special handling. Genfs but also in-core setxattr handler */
 		!strcmp(sb->s_type->name, "sysfs") ||
 		!strcmp(sb->s_type->name, "pstore") ||
-- 
1.9.3

Re: [PATCH] selinux: fix setting of security labels on NFS

[Stephen Smalley]

On 06/04/2015 03:57 PM, J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
> 
> Before calling into the filesystem, vfs_setxattr calls
> security_inode_setxattr, which ends up calling selinux_inode_setxattr in
> our case.  That returns -EOPNOTSUPP whenever SBLABEL_MNT is not set.
> SBLABEL_MNT was supposed to be set by sb_finish_set_opts, which sets it
> only if selinux_is_sblabel_mnt returns true.
> 
> The selinux_is_sblabel_mnt logic was broken by eadcabc697e9 "SELinux: do
> all flags twiddling in one place", which didn't take into the account
> the SECURITY_FS_USE_NATIVE behavior that had been introduced for nfs
> with eb9ae686507b "SELinux: Add new labeling type native labels".
> 
> This caused setxattr's of security labels over NFSv4.2 to fail.
> 
> Cc: stable@kernel.org
> Cc: Eric Paris <eparis@redhat.com>
> Cc: David Quigley <dpquigl@davequigley.com>
> Reported-by: Richard Chan <rc556677@outlook.com>
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>

Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>

> ---
>  security/selinux/hooks.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e8a060bd9677..171fb30e4b99 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -403,6 +403,7 @@ static int selinux_is_sblabel_mnt(struct super_block *sb)
>  	return sbsec->behavior == SECURITY_FS_USE_XATTR ||
>  		sbsec->behavior == SECURITY_FS_USE_TRANS ||
>  		sbsec->behavior == SECURITY_FS_USE_TASK ||
> +		sbsec->behavior == SECURITY_FS_USE_NATIVE ||
>  		/* Special handling. Genfs but also in-core setxattr handler */
>  		!strcmp(sb->s_type->name, "sysfs") ||
>  		!strcmp(sb->s_type->name, "pstore") ||
> 

Re: [PATCH] selinux: fix setting of security labels on NFS

[Paul Moore]

On Thursday, June 04, 2015 03:57:25 PM J. Bruce Fields wrote:
> From: "J. Bruce Fields" <bfields@redhat.com>
> 
> Before calling into the filesystem, vfs_setxattr calls
> security_inode_setxattr, which ends up calling selinux_inode_setxattr in
> our case.  That returns -EOPNOTSUPP whenever SBLABEL_MNT is not set.
> SBLABEL_MNT was supposed to be set by sb_finish_set_opts, which sets it
> only if selinux_is_sblabel_mnt returns true.
> 
> The selinux_is_sblabel_mnt logic was broken by eadcabc697e9 "SELinux: do
> all flags twiddling in one place", which didn't take into the account
> the SECURITY_FS_USE_NATIVE behavior that had been introduced for nfs
> with eb9ae686507b "SELinux: Add new labeling type native labels".
> 
> This caused setxattr's of security labels over NFSv4.2 to fail.
> 
> Cc: stable@kernel.org
> Cc: Eric Paris <eparis@redhat.com>
> Cc: David Quigley <dpquigl@davequigley.com>
> Reported-by: Richard Chan <rc556677@outlook.com>
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> ---
>  security/selinux/hooks.c | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.  In the future, you don't have to worry about marking it for 
stable, I'll take care of that when I merge it into the tree.

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e8a060bd9677..171fb30e4b99 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -403,6 +403,7 @@ static int selinux_is_sblabel_mnt(struct super_block
> *sb) return sbsec->behavior == SECURITY_FS_USE_XATTR ||
>  		sbsec->behavior == SECURITY_FS_USE_TRANS ||
>  		sbsec->behavior == SECURITY_FS_USE_TASK ||
> +		sbsec->behavior == SECURITY_FS_USE_NATIVE ||
>  		/* Special handling. Genfs but also in-core setxattr handler */
>  		!strcmp(sb->s_type->name, "sysfs") ||
>  		!strcmp(sb->s_type->name, "pstore") ||

-- 
paul moore
www.paul-moore.com

Re: [PATCH] selinux: fix setting of security labels on NFS

[J. Bruce Fields]

On Fri, Jun 05, 2015 at 02:28:51PM -0400, Paul Moore wrote:
> On Thursday, June 04, 2015 03:57:25 PM J. Bruce Fields wrote:
> > From: "J. Bruce Fields" <bfields@redhat.com>
> > 
> > Before calling into the filesystem, vfs_setxattr calls
> > security_inode_setxattr, which ends up calling selinux_inode_setxattr in
> > our case.  That returns -EOPNOTSUPP whenever SBLABEL_MNT is not set.
> > SBLABEL_MNT was supposed to be set by sb_finish_set_opts, which sets it
> > only if selinux_is_sblabel_mnt returns true.
> > 
> > The selinux_is_sblabel_mnt logic was broken by eadcabc697e9 "SELinux: do
> > all flags twiddling in one place", which didn't take into the account
> > the SECURITY_FS_USE_NATIVE behavior that had been introduced for nfs
> > with eb9ae686507b "SELinux: Add new labeling type native labels".
> > 
> > This caused setxattr's of security labels over NFSv4.2 to fail.
> > 
> > Cc: stable@kernel.org
> > Cc: Eric Paris <eparis@redhat.com>
> > Cc: David Quigley <dpquigl@davequigley.com>
> > Reported-by: Richard Chan <rc556677@outlook.com>
> > Signed-off-by: J. Bruce Fields <bfields@redhat.com>
> > ---
> >  security/selinux/hooks.c | 1 +
> >  1 file changed, 1 insertion(+)
> 
> Applied, thanks.

Thanks!

> In the future, you don't have to worry about marking it for 
> stable, I'll take care of that when I merge it into the tree.

OK.  With roles reversed, I usually appreciate the stable tag from
submitters, just as a statement of their opinion as to whether it's
stable-worthy, which can always be overridden.

(I mean, this one seems obvious enough--one-liner, fixes a user-visible
regression--but in more complicated cases their opinion might be
useful.)

By the way, I suspect this requires (obvious) fixups to apply to some
older kernels, let me know if help's needed there.

--b.

> 
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index e8a060bd9677..171fb30e4b99 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -403,6 +403,7 @@ static int selinux_is_sblabel_mnt(struct super_block
> > *sb) return sbsec->behavior == SECURITY_FS_USE_XATTR ||
> >  		sbsec->behavior == SECURITY_FS_USE_TRANS ||
> >  		sbsec->behavior == SECURITY_FS_USE_TASK ||
> > +		sbsec->behavior == SECURITY_FS_USE_NATIVE ||
> >  		/* Special handling. Genfs but also in-core setxattr handler */
> >  		!strcmp(sb->s_type->name, "sysfs") ||
> >  		!strcmp(sb->s_type->name, "pstore") ||
> 
> -- 
> paul moore
> www.paul-moore.com

Re: [PATCH] selinux: fix setting of security labels on NFS

[Paul Moore]

On Mon, Jun 8, 2015 at 11:17 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Fri, Jun 05, 2015 at 02:28:51PM -0400, Paul Moore wrote:
>> On Thursday, June 04, 2015 03:57:25 PM J. Bruce Fields wrote:
>> > From: "J. Bruce Fields" <bfields@redhat.com>
>> >
>> > Before calling into the filesystem, vfs_setxattr calls
>> > security_inode_setxattr, which ends up calling selinux_inode_setxattr in
>> > our case.  That returns -EOPNOTSUPP whenever SBLABEL_MNT is not set.
>> > SBLABEL_MNT was supposed to be set by sb_finish_set_opts, which sets it
>> > only if selinux_is_sblabel_mnt returns true.
>> >
>> > The selinux_is_sblabel_mnt logic was broken by eadcabc697e9 "SELinux: do
>> > all flags twiddling in one place", which didn't take into the account
>> > the SECURITY_FS_USE_NATIVE behavior that had been introduced for nfs
>> > with eb9ae686507b "SELinux: Add new labeling type native labels".
>> >
>> > This caused setxattr's of security labels over NFSv4.2 to fail.
>> >
>> > Cc: stable@kernel.org
>> > Cc: Eric Paris <eparis@redhat.com>
>> > Cc: David Quigley <dpquigl@davequigley.com>
>> > Reported-by: Richard Chan <rc556677@outlook.com>
>> > Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>> > ---
>> >  security/selinux/hooks.c | 1 +
>> >  1 file changed, 1 insertion(+)
>>
>> Applied, thanks.
>
> Thanks!
>
>> In the future, you don't have to worry about marking it for
>> stable, I'll take care of that when I merge it into the tree.
>
> OK.  With roles reversed, I usually appreciate the stable tag from
> submitters, just as a statement of their opinion as to whether it's
> stable-worthy, which can always be overridden.

Every subsystem is different, but in general I haven't found it too
difficult to determine if a given patch is stable worthy; on the rare
occasion that I'm uncertain I'll ask the submitter for their opinion.
I wouldn't say I discourage people from adding a stable tag, it is
just that I don't require people to add one to make it into my stable
queue, and I don't automatically add it to the queue if the poster
does tag it so (although that said, I don't recall ever removing a
stable CC).

> (I mean, this one seems obvious enough--one-liner, fixes a user-visible
> regression--but in more complicated cases their opinion might be
> useful.)

This patch is definitely a stable no-brainer.

> By the way, I suspect this requires (obvious) fixups to apply to some
> older kernels, let me know if help's needed there.

It may, I generally wait until the stable devs pick it up and if they
hit a merge conflict I fix it up, however, since you offered I may
kick it your way ;)

-- 
paul moore
www.paul-moore.com