On Fri, 29 Sep 2006, Paul Moore wrote: > > ... or related packet doesn't match ... > > Not sure what you mean by "related packet",
A related packet with conntrack would be an FTP data packet related to a specific FTP control session (where the conntrack is initialized, and has a secmark saved to it). > but if the check in step #2 > fails then the packet would be dropped. Ok. > The only case where I can see > this happening is that if the MLS/MCS constraints did not allow the > flow_in permission. This allows administrators to set specific MLS > labels for any iptables "object". Yep, one thing to watch for here is packets arriving on a different interface for valid reasons (e.g. routing changes), but that's a policy issue. > > ... or you get no CIPSO label (e.g. ICMP from intermediate router) ... > > If there is no packet label that NetLabel recognizes and NetLabel is > configured to allow unlabeled traffic then the NetLabel SID generated in > step #1 above would be 0. Well, conntrack will say that this packet is related to the connection and CONNSECMARK will restore the secmark label to it (i.e. it'll have the same secmark as the initial syn packet). But, no CIPSO label. I guess this needs to be considered in any case, secmark or not. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
