netdev - Re: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with CIPSO & Smack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <822cf1e1-7a76-5b79-d277-f151e66b3693@schaufler-ca.com>
Date:	Wed, 6 Jul 2016 07:15:34 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Paul Moore <paul@...l-moore.com>
Cc:	David Miller <davem@...emloft.net>, dsa@...ulusnetworks.com,
	Linux-Netdev <netdev@...r.kernel.org>
Subject: Re: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with
 CIPSO & Smack

On 7/6/2016 5:50 AM, Paul Moore wrote:
> On Tue, Jul 5, 2016 at 8:38 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>> I have encountered a system hang with my Smack
>> networking tests that bisects to the change below.
>> I can't say that I have any idea why the change
>> would impact the Smack processing, but there appears
>> to be some serious packet processing going on. The
>> Smack code is using CIPSO on the loopback interface.
>> The test is supposed to verify that labels can be
>> set on the packets using CIPSO. Unlabeled packets
>> do not appear to be impacted. I do not know if SELinux
>> is affected, and if not, why not. Smack and SELinux
>> use CIPSO differently.
> For the past several months I've been running the SELinux testsuite on
> a weekly basis against Linus' kernel plus the SELinux and audit
> development trees and I haven't noticed any problems that haven't
> already been reported.  While not exhaustive, the testsuite does
> exercise the NetLabel/CIPSO code.  I'll see if I can take a closer
> look at the Smack code, but do you rely on the inet_skb_param values
> in Smack?  We did have a similar problem in the NetLabel core code
> that we fixed with 04f81f0154e4bf002be6f4d85668ce1257efa4d9; it's
> possible there is a similar problem in code that we just aren't
> exercising with SELinux at the moment.

I reported that problem, and that problem was fixed.

I'm looking at the Linus tree and see no structure inet_skb_param.

> * https://github.com/SELinuxProject/selinux-testsuite
> * https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext
>
>> commit c3f1010b30f7fc611139cfb702a8685741aa6827
>> Merge: ca4aa97 0b922b7
>> Author: David S. Miller <davem@...emloft.net>
>> Date:   Wed May 11 19:31:40 2016 -0400
>>
>>     Merge branch 'vrf-pktinfo'
>>
>>     David Ahern says:
>>
>>     ====================
>>     net: vrf: Fixup PKTINFO to return enslaved device index
>>
>>     Applications such as OSPF and BFD need the original ingress device not
>>     the VRF device; the latter can be derived from the former. To that end
>>     move the packet intercept from an rx handler that is invoked by
>>     __netif_receive_skb_core to the ipv4 and ipv6 receive processing.
>>
>>     IPv6 already saves the skb_iif to the control buffer in ipv6_rcv. Since
>>     the skb->dev has not been switched the cb has the enslaved device. Make
>>     the same happen for IPv4 by adding the skb_iif to inet_skb_parm and set
>>     it in ipv4 code after clearing the skb control buffer similar to IPv6.
>>     From there the pktinfo can just pull it from cb with the PKTINFO_SKB_CB
>>     cast.
>>     ====================
>>
>>     Signed-off-by: David S. Miller <davem@...emloft.net>