On 06/02/2011 02:41 PM, Mr Dash Four wrote: > >>> 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 is subject to a net->fw rule, then certainly no local program created it. > > 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! > It is only superfluous if there is an earlier unrestricted 'dropInvalid' rule. The reason that dropInvalid is in the Drop default action is so it won't be logged and I won't have to answer silly questions about it when people see it in their logs. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
