Re: Network hang after c3f1010b30f7fc611139cfb702a8685741aa6827 with CIPSO & Smack

[Casey Schaufler <casey@schaufler-ca.com>]

On 7/6/2016 7:03 AM, Paul Moore wrote:
> On Wed, Jul 6, 2016 at 8:50 AM, Paul Moore <paul@paul-moore.com> wrote:
>> On Tue, Jul 5, 2016 at 8:38 PM, Casey Schaufler <casey@schaufler-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.

That would not surprise me at all. Smack uses CIPSO more
extensively than SELinux.

>   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.

That was where my long weekend was spent. Except for a trivial
change in the signal delivery code, there haven't been changes
in Smack recently.

That's why I took the bisect route to try to find the problem.

I am perfectly willing to accept that there's something that
I'm doing wrong (I often do things wrong). In this case, it's
got to be something that I've been getting away with for quite
some time.