On 7/6/2016 5:50 AM, Paul Moore 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.
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 <da...@davemloft.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 <da...@davemloft.net>
