>> I will have the opportunity to try this and will find one way or >> another, but consider this: I currently have Drop in my fw2vpn chain. >> There is dropInvalid in it (albeit not audited, though if I knew what I >> will discover I might as well triggered it - hindsight is 20-20 as they >> say, eh?). The packet to which this AVC relates would have been dropped, >> but AVC was issued instead. Why? >> > > If you are going to the trouble to assign a security context to these > packets, then surely you are also ACCEPTing them in the rules file. So > the Drop default action is not involved. > Not really! I am assigning a context "unauthorised_t" for example (see my brief secmark example in this very thread), which does not accept packets at all. Assigning a security context does not necessarily mean the packet would get accepted - that is sheer nonsense to suggest something like that. I could assign a context "http_client_t" and have a DROP rule for this in my rules file.
Besides, in the case I highlighted in my first post, I am not assigning any context (rather, SELinux does) and the AVC is issued before the packet is accepted or dropped - it doesn't go that far, I don't think, but will have the opportunity later tonight to test this assertion and judge one way or another. > If the state is INVALID, there is usually nothing to restore. And if you > use dropInvalid, then there is nothing to save. > OK, that pretty much explains it. ------------------------------------------------------------------------------ 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
