> It is NEW *or* INVALID. > That may pose a problem then. The existing catch-all I have has ctstate NEW and slaps an "unauthorised_t" mark on every NEW packet regardless what happens down the chain.
Since the mark listed in my security alert log has this packet marked as "unlabeled_t" (that is an indication that no secure marking was applied to that packet), that makes me think the ctstate was not new and that the packet may have been invalid, hence escaping my catch-all secmark statement. That is fine and I suspect your patch would work if that was the case, but this would present a problem with packets which are NEW *and* INVALID as whichever way I place the ":NI" labelling it will get either 1) overwritten by the next catch-all (which has NEW only); or 2) I will get all my new packets labelled with my ":NI" label (invalid_t), which isn't good to me either. Here is a small example so I can illustrate this: 1) system_u:object_r:invalid_packet_t:s0 O:NI system_u:object_r:unauthorised_packet_t:s0 O:N [other statements] 2) system_u:object_r:unauthorised_packet_t:s0 O:N system_u:object_r:invalid_packet_t:s0 O:NI [other statements] In 1) above I will have all new packets not matching any of the [other statements] marked with "unauthorised_packet_t", *including* those with ctstate INVALID, which is not what I want. In 2) above I will have all new packets not matching any of the [other statements] marked with "invalid_packet_t", which isn't what I want either. Suggestions are welcome! ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
