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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHC9VhRCWgqR1k8vB8hwhiVUyu-hndpuvg9rZPfurVoof65wYg@mail.gmail.com>
Date:	Wed, 6 Jul 2016 10:03:33 -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 8:50 AM, Paul Moore <paul@...l-moore.com> 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.
>
> * https://github.com/SELinuxProject/selinux-testsuite
> * https://copr.fedorainfracloud.org/coprs/pcmoore/kernel-secnext

I just ran some additional SELinux/NetLabel tests on 4.7-rc6
(+selinux#next +audit#next) and everything worked as expected.  This
is looking more and more like a Smack specific bug.  I took a quick
look at the NetLabel/CIPSO code as well as some of the Smack code and
nothing jumped out at me as obviously wrong, but it has been years
since I've looked at the Smack code in any detail.

I'm happy to help debug, but I think it might be more helpful if you
take a closer look at the Smack code first.

-- 
paul moore
www.paul-moore.com