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