All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Salyzyn <salyzyn@android.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	linux-kernel@vger.kernel.org, Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@parisplace.org>,
	James Morris <james.l.morris@oracle.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] general protection fault in sock_has_perm
Date: Tue, 30 Jan 2018 23:46:14 +0100	[thread overview]
Message-ID: <20180130224614.GA13647@kroah.com> (raw)
In-Reply-To: <99c11fa6-ad9a-830c-467e-6a56e78aecf8@android.com>

On Tue, Jan 30, 2018 at 11:00:04AM -0800, Mark Salyzyn wrote:
> On 01/19/2018 09:41 AM, Stephen Smalley wrote:
> > If we can't safely dereference the sock in these hooks, then that seems
> > to point back to the approach used in my original code, where in
> > ancient history I had sock_has_perm() take the socket and use its inode
> > i_security field instead of the sock.  commit
> > 253bfae6e0ad97554799affa0266052968a45808 switched them to use the sock
> > instead.
> 
> Because of the nature of this problem (hard to duplicate, no clear path), I
> am understandably not comfortable reverting and submitting for testing in
> order to prove this point. It is disruptive because it changes several
> subroutine call signatures.
> 
> AFAIK this looks like a user request racing in without reference counting or
> RCU grace period in the callers (could be viewed as not an issue with
> security code). Effectively fixed in 4.9-stable, but broken in 4.4-stable.
> 
> hygiene, KISS and small, is all I do feel comfortable to submit to
> 4.4-stable without pulling in all the infrastructure improvements.
> 
> -- Mark
> 
> ---
>  security/selinux/hooks.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 34427384605d..be68992a28cb 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4066,6 +4066,8 @@ static int sock_has_perm(struct task_struct *task,
> struct sock *sk, u32 perms)
>      struct lsm_network_audit net = {0,};
>      u32 tsid = task_sid(task);
> 
> +    if (!sksec)
> +        return -EFAULT;
>      if (sksec->sid == SECINITSID_KERNEL)
>          return 0;
> 

This looks sane to me as a simple 4.4-only fix.  If the SELinux
maintainer acks it, I can easily queue this up.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Mark Salyzyn <salyzyn@android.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	linux-kernel@vger.kernel.org, Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@parisplace.org>,
	James Morris <james.l.morris@oracle.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] general protection fault in sock_has_perm
Date: Tue, 30 Jan 2018 23:46:14 +0100	[thread overview]
Message-ID: <20180130224614.GA13647@kroah.com> (raw)
In-Reply-To: <99c11fa6-ad9a-830c-467e-6a56e78aecf8@android.com>

On Tue, Jan 30, 2018 at 11:00:04AM -0800, Mark Salyzyn wrote:
> On 01/19/2018 09:41 AM, Stephen Smalley wrote:
> > If we can't safely dereference the sock in these hooks, then that seems
> > to point back to the approach used in my original code, where in
> > ancient history I had sock_has_perm() take the socket and use its inode
> > i_security field instead of the sock.  commit
> > 253bfae6e0ad97554799affa0266052968a45808 switched them to use the sock
> > instead.
> 
> Because of the nature of this problem (hard to duplicate, no clear path), I
> am understandably not comfortable reverting and submitting for testing in
> order to prove this point. It is disruptive because it changes several
> subroutine call signatures.
> 
> AFAIK this looks like a user request racing in without reference counting or
> RCU grace period in the callers (could be viewed as not an issue with
> security code). Effectively fixed in 4.9-stable, but broken in 4.4-stable.
> 
> hygiene, KISS and small, is all I do feel comfortable to submit to
> 4.4-stable without pulling in all the infrastructure improvements.
> 
> -- Mark
> 
> ---
> �security/selinux/hooks.c | 2 ++
> �1 file changed, 2 insertions(+)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 34427384605d..be68992a28cb 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4066,6 +4066,8 @@ static int sock_has_perm(struct task_struct *task,
> struct sock *sk, u32 perms)
> ���� struct lsm_network_audit net = {0,};
> ���� u32 tsid = task_sid(task);
> 
> +��� if (!sksec)
> +��� ��� return -EFAULT;
> ���� if (sksec->sid == SECINITSID_KERNEL)
> ���� ��� return 0;
> 

This looks sane to me as a simple 4.4-only fix.  If the SELinux
maintainer acks it, I can easily queue this up.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg KH)
To: linux-security-module@vger.kernel.org
Subject: [PATCH] general protection fault in sock_has_perm
Date: Tue, 30 Jan 2018 23:46:14 +0100	[thread overview]
Message-ID: <20180130224614.GA13647@kroah.com> (raw)
In-Reply-To: <99c11fa6-ad9a-830c-467e-6a56e78aecf8@android.com>

On Tue, Jan 30, 2018 at 11:00:04AM -0800, Mark Salyzyn wrote:
> On 01/19/2018 09:41 AM, Stephen Smalley wrote:
> > If we can't safely dereference the sock in these hooks, then that seems
> > to point back to the approach used in my original code, where in
> > ancient history I had sock_has_perm() take the socket and use its inode
> > i_security field instead of the sock.  commit
> > 253bfae6e0ad97554799affa0266052968a45808 switched them to use the sock
> > instead.
> 
> Because of the nature of this problem (hard to duplicate, no clear path), I
> am understandably not comfortable reverting and submitting for testing in
> order to prove this point. It is disruptive because it changes several
> subroutine call signatures.
> 
> AFAIK this looks like a user request racing in without reference counting or
> RCU grace period in the callers (could be viewed as not an issue with
> security code). Effectively fixed in 4.9-stable, but broken in 4.4-stable.
> 
> hygiene, KISS and small, is all I do feel comfortable to submit to
> 4.4-stable without pulling in all the infrastructure improvements.
> 
> -- Mark
> 
> ---
> ?security/selinux/hooks.c | 2 ++
> ?1 file changed, 2 insertions(+)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 34427384605d..be68992a28cb 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4066,6 +4066,8 @@ static int sock_has_perm(struct task_struct *task,
> struct sock *sk, u32 perms)
> ???? struct lsm_network_audit net = {0,};
> ???? u32 tsid = task_sid(task);
> 
> +??? if (!sksec)
> +??? ??? return -EFAULT;
> ???? if (sksec->sid == SECINITSID_KERNEL)
> ???? ??? return 0;
> 

This looks sane to me as a simple 4.4-only fix.  If the SELinux
maintainer acks it, I can easily queue this up.

thanks,

greg k-h
--
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

  reply	other threads:[~2018-01-30 22:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18 21:58 [PATCH] general protection fault in sock_has_perm Mark Salyzyn
2018-01-18 21:58 ` Mark Salyzyn
2018-01-18 22:36 ` Paul Moore
2018-01-18 22:36   ` Paul Moore
2018-01-19 15:49   ` Mark Salyzyn
2018-01-19 15:49     ` Mark Salyzyn
2018-01-19 17:06     ` Paul Moore
2018-01-19 17:06       ` Paul Moore
2018-01-19 17:37       ` Casey Schaufler
2018-01-19 17:37         ` Casey Schaufler
2018-01-19 17:46       ` Mark Salyzyn
2018-01-19 17:46         ` Mark Salyzyn
2018-01-19  7:48 ` Greg KH
2018-01-19  7:48   ` Greg KH
2018-01-19 17:19 ` Stephen Smalley
2018-01-19 17:19   ` Stephen Smalley
2018-01-19 17:34   ` Mark Salyzyn
2018-01-19 17:34     ` Mark Salyzyn
2018-01-19 17:41   ` Stephen Smalley
2018-01-19 17:41     ` Stephen Smalley
2018-01-30 19:00     ` Mark Salyzyn
2018-01-30 19:00       ` Mark Salyzyn
2018-01-30 22:46       ` Greg KH [this message]
2018-01-30 22:46         ` Greg KH
2018-01-30 22:46         ` Greg KH
2018-01-31  9:06         ` Paul Moore
2018-01-31  9:06           ` Paul Moore
2018-02-01  8:18           ` Greg KH
2018-02-01  8:18             ` Greg KH

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=20180130224614.GA13647@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=eparis@parisplace.org \
    --cc=james.l.morris@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=salyzyn@android.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=serge@hallyn.com \
    --cc=stable@vger.kernel.org \
    /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.