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]

Date:	Wed, 6 Jul 2016 10:37:53 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Casey Schaufler <casey@...aufler-ca.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 Wed, Jul 6, 2016 at 10:15 AM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> 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.

Yep, I know, that is why I included the commit ID.

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

I mistakenly added an extra "a", look for "struct inet_skb_parm" near
the top of include/net/ip.h; it was modified as part of the
pull-request/merge you mentioned.

-- 
paul moore
www.paul-moore.com