From: Casey Schaufler <casey@schaufler-ca•com>
To: Eric Dumazet <eric.dumazet@gmail•com>
Cc: Eric Paris <eparis@parisplace•org>,
Paul Moore <paul@paul-moore•com>,
David Miller <davem@davemloft•net>,
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, john.johansen@canonical•com,
LSM <linux-security-module@vger•kernel.org>,
netdev <netdev@vger•kernel.org>,
Casey Schaufler <casey@schaufler-ca•com>
Subject: Re: [PATCH] ipv4: tcp: security_sk_alloc() needed for unicast_sock
Date: Thu, 09 Aug 2012 14:53:03 -0700 [thread overview]
Message-ID: <5024313F.1010404@schaufler-ca.com> (raw)
In-Reply-To: <1344547743.31104.582.camel@edumazet-glaptop>
On 8/9/2012 2:29 PM, Eric Dumazet wrote:
> On Thu, 2012-08-09 at 16:06 -0400, Eric Paris wrote:
>> NAK.
>>
>> I personally think commit be9f4a44e7d41cee should be reverted until it
>> is fixed. Let me explain what all I believe it broke and how.
>>
> Suggesting to revert this commit while we have known working fixes is a
> bit of strange reaction.
A couple of potential short term workarounds have been identified,
but no one is happy with them for the long term. That does not
qualify as a "working fix" in engineering terms.
> I understand you are upset, but I believe we tried to fix it.
>
>> Old callchain of the creation of the 'equivalent' socket previous to
>> the patch in question just for reference:
>>
>> inet_ctl_sock_create
>> sock_create_kern
>> __sock_create
>> pf->create (inet_create)
>> sk_alloc
>> sk_prot_alloc
>> security_sk_alloc()
>>
>>
>> This WAS working properly. All of it.
> Nobody denies it. But acknowledge my patch uncovered a fundamental
> issue.
>
> What kind of 'security module' can decide to let RST packets being sent
> or not, on a global scale ? (one socket for the whole machine)
The short answer is "any security module that wants to".
And before we go any further, I'm a little surprised that
SELinux doesn't do this already.
>
> smack_sk_alloc_security() uses smk_of_current() : What can be the
> meaning of smk_of_current() in the context of 'kernel' sockets...
Yes, and all of it's callers - to date - have had an appropriate
value of current. It is using the API in the way it is supposed to.
It is assuming a properly formed socket. You want to give it a
cobbled together partial socket structure without task context.
Your predecessor did not have this problem.
>
> Your patch tries to maintain this status quo.
>
> In fact I suggest the following one liner patch, unless you can really
> demonstrate what can be the meaning of providing a fake socket for these
> packets.
>
> This mess only happened because ip_append_data()/ip_push_pending_frames()
> are so complex and use an underlying socket.
>
> But this socket should not be ever used outside of its scope.
>
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 76dde25..ec410e0 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -1536,6 +1536,7 @@ void ip_send_unicast_reply(struct net *net, struct sk_buff *skb, __be32 daddr,
> arg->csumoffset) = csum_fold(csum_add(nskb->csum,
> arg->csum));
> nskb->ip_summed = CHECKSUM_NONE;
> + skb_orphan(nskb);
> skb_set_queue_mapping(nskb, skb_get_queue_mapping(skb));
> ip_push_pending_frames(sk, &fl4);
> }
>
>
>
next prev parent reply other threads:[~2012-08-09 21:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <50215A7E.8000701@linaro.org>
[not found] ` <1344462889.28967.328.camel@edumazet-glaptop>
[not found] ` <5022FD9A.4020603@schaufler-ca.com>
[not found] ` <1695034.0lrQgQPOMT@sifl>
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
[not found] ` <CACLa4ptkvKj2GT4ZL+msMuWOHW885Hugk8nz3hvptOoY9-totw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-08-09 20:19 ` Paul Moore
2012-08-09 21:29 ` Eric Dumazet
2012-08-09 21:53 ` Casey Schaufler [this message]
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
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=5024313F.1010404@schaufler-ca.com \
--to=casey@schaufler-ca$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=eparis@parisplace$(echo .)org \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=james.l.morris@oracle$(echo .)com \
--cc=john.johansen@canonical$(echo .)com \
--cc=johnstul@us$(echo .)ibm.com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-security-module@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=paul@paul-moore$(echo .)com \
--cc=selinux@tycho$(echo .)nsa.gov \
--cc=serge@hallyn$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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