public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Eric Paris <eparis@parisplace.org>,
	John Stultz <johnstul@us.ibm.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	lkml <linux-kernel@vger.kernel.org>,
	James Morris <james.l.morris@oracle.com>,
	selinux@tycho.nsa.gov, Eric Dumazet <edumazet@google.com>,
	john.johansen@canonical.com
Subject: Re: NULL pointer dereference in selinux_ip_postroute_compat
Date: Wed, 08 Aug 2012 16:35:08 -0400	[thread overview]
Message-ID: <2294220.dmCbVvF3Tg@sifl> (raw)
In-Reply-To: <1344456578.28967.244.camel@edumazet-glaptop>

On Wednesday, August 08, 2012 10:09:38 PM Eric Dumazet wrote:
> On Wed, 2012-08-08 at 15:59 -0400, Eric Paris wrote:
> > Seems wrong.  We shouldn't ever need ifdef CONFIG_SECURITY in core
> > code.
> 
> Sure but it seems include file misses an accessor for this.
> 
> We could add it on a future cleanup patch, as Paul mentioned.

Actually, the issue is that the shared socket doesn't have an init/alloc 
function to do the LSM allocation like we do with other sockets so Eric's 
patch does it as part of ip_send_unicast_reply().

If we look at the relevant part of Eric's patch:

 +#ifdef CONFIG_SECURITY
 +       if (!sk->sk_security && security_sk_alloc(sk, PF_INET, GFP_ATOMIC))
 +                       goto out;
 +#endif

... if we were to remove the CONFIG_SECURITY conditional we would end up 
calling security_sk_alloc() each time through in the CONFIG_SECURITY=n case as 
sk->sk_security would never be initialized to a non-NULL value.  In the 
CONFIG_SECURITY=y case it should only be called once as security_sk_alloc() 
should set sk->sk_security to a LSM blob.

> >  Ifndef CONF_SECURITY then security_sk_alloc() is a static
> > 
> > inline return 0;   I guess the question is "Where did the sk come
> > from"?  Why wasn't security_sk_alloc() called when it was allocated?
> > Should it have been updated at some time and that wasn't done either?
> > Seems wrong to be putting packets on the queue for a socket where the
> > security data was never allocated and was never set to its proper
> > state.
> 
> IMHO it seems wrong to even care about security for internal sockets.
>
> They are per cpu, shared for all users on the machine.

The issue, from a security point of view, is that these sockets are sending 
network traffic; even if it is just resets and timewait ACKs, it is still 
network traffic and the LSMs need to be able to enforce security policy on 
this traffic.  After all, what would you say if your firewall let these same 
packets pass without any filtering?

The issue I'm struggling with at present is how should we handle this traffic 
from a LSM perspective.  The label based LSMs, e.g. SELinux and Smack, use the 
LSM blob assigned to locally generated outbound traffic to identify the 
traffic and apply the security policy, so not only do we have to resolve the 
issue of ensuring the traffic is labeled correctly, we have to do it with a 
shared socket (although the patch didn't change the shared nature of the 
socket).

For those who are interested, I think the reasonable labeling solution here is 
to go with SECINITSID_KERNEL/kernel_t for SELinux and likely the ambient label 
for Smack as in both the TCP reset and timewait ACK there shouldn't be any 
actual user data present.

-- 
paul moore
www.paul-moore.com


  parent reply	other threads:[~2012-08-08 20:35 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-07 18:12 NULL pointer dereference in selinux_ip_postroute_compat John Stultz
2012-08-07 21:50 ` Paul Moore
2012-08-07 21:58   ` John Stultz
2012-08-07 22:01     ` Paul Moore
2012-08-07 22:17       ` Serge E. Hallyn
2012-08-07 22:23         ` Paul Moore
2012-08-07 22:37         ` John Stultz
2012-08-08 19:14           ` John Stultz
2012-08-08 19:26             ` Paul Moore
2012-08-08 19:38               ` Eric Dumazet
2012-08-08 19:49                 ` John Stultz
2012-08-08 20:04                   ` Eric Dumazet
2012-08-08 19:50                 ` Paul Moore
2012-08-08 20:04                   ` Eric Dumazet
2012-08-08 19:59                 ` Eric Paris
2012-08-08 20:09                   ` Eric Dumazet
2012-08-08 20:32                     ` Eric Dumazet
2012-08-08 20:46                       ` Paul Moore
2012-08-08 21:54                         ` Eric Dumazet
2012-08-09  0:00                           ` Casey Schaufler
2012-08-09 13:30                             ` Paul Moore
2012-08-09 14:27                               ` Eric Dumazet
2012-08-09 15:04                                 ` Paul Moore
2012-08-09 14:50                               ` [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock Eric Dumazet
2012-08-09 15:07                                 ` Paul Moore
2012-08-09 15:36                                   ` Eric Dumazet
2012-08-09 15:59                                     ` Paul Moore
2012-08-09 16:05                                     ` Eric Paris
2012-08-09 16:09                                       ` Paul Moore
2012-08-09 17:46                                       ` Eric Dumazet
2012-08-09 20:06                                 ` Eric Paris
2012-08-09 20:19                                   ` Paul Moore
2012-08-09 21:29                                   ` Eric Dumazet
2012-08-09 21:53                                     ` Casey Schaufler
2012-08-09 22:05                                       ` Eric Dumazet
2012-08-09 22:26                                         ` Casey Schaufler
2012-08-09 23:38                                     ` David Miller
2012-08-09 23:56                                       ` [PATCH] ipv4: tcp: unicast_sock should not land outside of TCP stack Eric Dumazet
2012-08-10  4:05                                         ` David Miller
2012-08-08 20:35                     ` Paul Moore [this message]
2012-08-08 20:51                       ` NULL pointer dereference in selinux_ip_postroute_compat Eric Paris
2012-08-08 21:03                         ` Paul Moore
2012-08-08 21:09                           ` Eric Paris
2012-08-08 19:29             ` Eric Dumazet
2012-08-08 16:58         ` John Johansen
2012-08-07 22:26       ` John Stultz
2012-08-07 22:31         ` John Stultz

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=2294220.dmCbVvF3Tg@sifl \
    --to=paul@paul-moore.com \
    --cc=edumazet@google.com \
    --cc=eparis@parisplace.org \
    --cc=eric.dumazet@gmail.com \
    --cc=james.l.morris@oracle.com \
    --cc=john.johansen@canonical.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=selinux@tycho.nsa.gov \
    --cc=serge@hallyn.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox