>> 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. >> > > It was you who said that you get the AVCs during connection close. If > you were not accepting connections on the port, then how did you get so > far as to be closing one? > A few things: I didn't say that I am getting this AVC during "connection close" - I am having syscall=close reported in the AVC, which I *assume* is during connection close, though I cannot be 100% certain. Second, I also said in my initial post that the host and port to which this packet relates are accepted by both SELinux and shorewall - this relates to connections which carry a valid state and packets which have valid tcp flags. This connection stream is properly marked in my secmarks file - nothing suspicious there.
The problem arises, I assume, when a packet, even though addressed to host:port authorised by shorewall, has an invalid state for whatever reason, thus does not fulfil the secmark requirement, is not properly marked and as a result avc is issued by SELinux. Whether this packet proceeds further and is either "accepted" with its state invalid, dropped as a result of dropInvalid, or whether everything after the issue of avc is halted by SELinux is a matter for debate. > If you have an ACCEPT rule for 'net fw tcp xxx' and an INVALID state > packet arrives for tcp xxx, you are going to ACCEPT it unless you have > the dropInvalid rule at the top of your rules file. And the packet will > have no secmark label because it matched none of your secmark rules. > Or, this packet won't even make it that far and will be halted by SELinux as the program which creates it doesn't have the permissions to do that - as I already wrote earlier, this is something I am going to find out. If it turns out that what you wrote in your last paragraph is right, then this is another issue which needs correcting in shorewall because I cannot see any sense whatsoever in including dropInvalid in the Drop chain as the packet, as you put it above, will already be accepted, rendering all this pretty-looking actions listed in Drop/Reject completely meaningless! ------------------------------------------------------------------------------ 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
