I have started receiving a rather "interesting" security alert (it happened twice in the last 24 hours or so) in the audit logs from my tun0 device. It is about a packet destined out to a well-known (and authorised) host and port, but with the packet class security-marked as "unlabelled" (unlabeled_t security type to be precise). This is baffling not least because I have a "catch-all" statement in my secmark file like this: system_u:object_r:unauthorised_packet_t:s0 O:N ... SAVE O:N RESTORE O:ER This is properly translated by shorewall to: -A tcout -m conntrack --ctstate NEW -j SECMARK --selctx system_u:object_r:unauthorised_packet_t:s0 -A tcout -m conntrack --ctstate NEW -j CONNSECMARK --save -A tcout -m conntrack --ctstate ESTABLISHED,RELATED -j CONNSECMARK --restore Now, the security alert I am getting I suspect is happening when the connection closes (syscall=close in that security alert), so what could be the reason that my catch-all above slips this packet through without marking it and how can I avoid this? Could it be that the packet is "invalid" or is there another reason for this? ------------------------------------------------------------------------------ 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. Data protection magic? Nope - It''s vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev
On 06/02/2011 07:55 AM, Mr Dash Four wrote:> I have started receiving a rather "interesting" security alert (it > happened twice in the last 24 hours or so) in the audit logs from my > tun0 device. It is about a packet destined out to a well-known (and > authorised) host and port, but with the packet class security-marked as > "unlabelled" (unlabeled_t security type to be precise). This is baffling > not least because I have a "catch-all" statement in my secmark file like > this: > > system_u:object_r:unauthorised_packet_t:s0 O:N > ... > SAVE O:N > RESTORE O:ER > > This is properly translated by shorewall to: > > -A tcout -m conntrack --ctstate NEW -j SECMARK --selctx > system_u:object_r:unauthorised_packet_t:s0 > -A tcout -m conntrack --ctstate NEW -j CONNSECMARK --save > -A tcout -m conntrack --ctstate ESTABLISHED,RELATED -j CONNSECMARK --restore > > Now, the security alert I am getting I suspect is happening when the > connection closes (syscall=close in that security alert), so what could > be the reason that my catch-all above slips this packet through without > marking it and how can I avoid this? Could it be that the packet is > "invalid" or is there another reason for this?The attached (untested) patch implements an ''NI'' suffix. See if that corrects the problem. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 06/02/2011 09:40 AM, Mr Dash Four wrote:> >> The attached (untested) patch implements an ''NI'' suffix. See if that >> corrects the problem. >> > Thanks! By looking at that patch, it takes ":NI" in the secmark''s STATE > sub-column to mark packets with cstate NEW,INVALID, is that right?That''s correct.> If so, and if the reason for me getting this security alerts is > probably because the packet may have been invalid, I think that > should fix it. Will apply it straight away.Okay -- Please let me know one way or the other. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> Okay -- Please let me know one way or the other. >Sure, but I would need to give it at least a day or so as this is not a very common occurrence - it only happened twice in the last 24 hours. I am also going to be auditing these packets to make sure. ------------------------------------------------------------------------------ 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
>> Thanks! By looking at that patch, it takes ":NI" in the secmark''s STATE >> sub-column to mark packets with cstate NEW,INVALID, is that right? >> > > That''s correct. >Does cstate "NEW,INVALID" means packets with cstate NEW *or* INVALID or NEW *and* INVALID? It is important as that kind of matching is not first match wins and I need to distinguish those from my other "catch-all" marking. ------------------------------------------------------------------------------ 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
On 6/2/11 10:29 AM, Mr Dash Four wrote:> > >>> Thanks! By looking at that patch, it takes ":NI" in the secmark''s STATE >>> sub-column to mark packets with cstate NEW,INVALID, is that right? >>> >> >> That''s correct. >> > Does cstate "NEW,INVALID" means packets with cstate NEW *or* INVALID or > NEW *and* INVALID? It is important as that kind of matching is not first > match wins and I need to distinguish those from my other "catch-all" > marking. >It is NEW *or* INVALID. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 06/02/2011 09:46 AM, Mr Dash Four wrote:> >> Okay -- Please let me know one way or the other. >> > Sure, but I would need to give it at least a day or so as this is not a > very common occurrence - it only happened twice in the last 24 hours.That further suggests that it is due to a packet in the invalid state. Another way to have corrected this would probably have been to add this in the NEW section of the rules file. dropInvalid net fw -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> 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
On 06/02/2011 10:55 AM, Mr Dash Four wrote:> >> 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* > INVALIDThat is impossible! A packet is in one and only one state. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> That further suggests that it is due to a packet in the invalid state. > Another way to have corrected this would probably have been to add this > in the NEW section of the rules file. > > dropInvalid net fw >Good suggestion, but isn''t that section applicable to packets with ctstate NEW? If so, I am not certain the reported packet was new as if it was new my catch-all security marking would have caught it and SELinux would have reported it as "unauthorised_t". I have this at the very top of my secmark file: system_u:object_r:unauthorised_packet_t:s0 O:N So, according to this if the packet was NEW and it was invalid the marking would have been "unauthorised". SELinux reported this as "unlabelled" which to me indicates that the ctstate was just INVALID, not NEW, or am I missing something? ------------------------------------------------------------------------------ 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
> That is impossible! A packet is in one and only one state. >Ah, right! So, if packet is invalid, regardless of whether it is new or not, its ctstate is INVALID, is that so? If that is the case then, you should amend the patch you send me to mark packets with invalid state only as these are the ones I am interested in (you may keep the :NI as extra option by all means, but in my specific case I would need INVALID only). ------------------------------------------------------------------------------ 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
On 6/2/11 11:03 AM, Mr Dash Four wrote:> >> That further suggests that it is due to a packet in the invalid state. >> Another way to have corrected this would probably have been to add this >> in the NEW section of the rules file. >> >> dropInvalid net fw >> > Good suggestion, but isn''t that section applicable to packets with > ctstate NEW?No -- it is valid for cstate NEW,INVALID. This is particularly important when Shorewall is first installed; the first time it is started, all packets that are part of existing connections will be in the INVALID state since the xt_conntrack module wasn''t loaded when those connections were created.> If so, I am not certain the reported packet was new as if > it was new my catch-all security marking would have caught it and > SELinux would have reported it as "unauthorised_t". I have this at the > very top of my secmark file: > > system_u:object_r:unauthorised_packet_t:s0 O:N > > So, according to this if the packet was NEW and it was invalid the > marking would have been "unauthorised". SELinux reported this as > "unlabelled" which to me indicates that the ctstate was just INVALID, > not NEW, or am I missing something?Again, there is no such thing as NEW and INVALID. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> Again, there is no such thing as NEW and INVALID. >So, it makes more sense then to have just INVALID in the secmarking sub-column because I do not wish to involve the NEW state at all - all I am interested in is the INVALID state! Also, what happens to the SAVE statement - is a change needed there as well, to incorporate the marking saved for the INVALID state given prior to 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
On 06/02/2011 11:40 AM, Mr Dash Four wrote:> >> Again, there is no such thing as NEW and INVALID. >> > So, it makes more sense then to have just INVALID in the secmarking > sub-column because I do not wish to involve the NEW state at all - all I > am interested in is the INVALID state! > > Also, what happens to the SAVE statement - is a change needed there as > well, to incorporate the marking saved for the INVALID state given prior > to it?The more I think about it, the more I favor inserting the dropInvalid rule in your rules file. If you do that, it is a moot point which security context INVALID packets have since they won''t be accepted. The way your ruleset is right now, you are ACCEPTing such packets; that creates new conntrack entries which will take some time to time out and be deleted. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> The more I think about it, the more I favor inserting the dropInvalid > rule in your rules file. If you do that, it is a moot point which > security context INVALID packets have since they won''t be accepted. The > way your ruleset is right now, you are ACCEPTing such packets; that > creates new conntrack entries which will take some time to time out and > be deleted. >I am not too sure that is (always) the case. SELinux hooks kick in even before a packet is traversed (when it goes out for example as was in the case I listed here) - if the process/program doesn''t have the right permissions set (my_program to send "http_client_t" type packets for example) then AVC is issued and no packet passes at all. Besides, when a security issue such as this is concerned, you can''t be too careful! It would also allow me additional flexibility as to what to do with/mark these packets as. ------------------------------------------------------------------------------ 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
On 06/02/2011 12:01 PM, Mr Dash Four wrote:> >> The more I think about it, the more I favor inserting the dropInvalid >> rule in your rules file. If you do that, it is a moot point which >> security context INVALID packets have since they won''t be accepted. The >> way your ruleset is right now, you are ACCEPTing such packets; that >> creates new conntrack entries which will take some time to time out and >> be deleted. >> > I am not too sure that is (always) the case. SELinux hooks kick in even > before a packet is traversed (when it goes out for example as was in the > case I listed here) - if the process/program doesn''t have the right > permissions set (my_program to send "http_client_t" type packets for > example) then AVC is issued and no packet passes at all. Besides, when a > security issue such as this is concerned, you can''t be too careful! It > would also allow me additional flexibility as to what to do with/mark > these packets as. >I''m betting that the AVC is only issued at the socket level (incoming and outgoing). So DROPped packets would not trigger it. At any rate, here''s a patch that implements '':I''. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> I''m betting that the AVC is only issued at the socket level (incoming > and outgoing). So DROPped packets would not trigger it. >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?> At any rate, here''s a patch that implements '':I''. >Thanks. How do I treat my existing SAVE and RESTORE statements: should I include the invalid state as well do you think (I think I should, but then again, I am not an expert)? ------------------------------------------------------------------------------ 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
On 6/2/11 12:38 PM, Mr Dash Four wrote:> >> I''m betting that the AVC is only issued at the socket level (incoming >> and outgoing). So DROPped packets would not trigger it. >> > 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.> >> At any rate, here''s a patch that implements '':I''. >> > Thanks. How do I treat my existing SAVE and RESTORE statements: should I > include the invalid state as well do you think (I think I should, but > then again, I am not an expert)? >If the state is INVALID, there is usually nothing to restore. And if you use dropInvalid, then there is nothing to save. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
>> 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
On 06/02/2011 01:08 PM, Mr Dash Four wrote:> > >>> 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.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? 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. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
>> 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
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 \________________________________________________ ------------------------------------------------------------------------------ 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
> If it is subject to a net->fw rule, then certainly no local program > created it. >You know very well that is not the case here.>> 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. >Answer me this then: If there is dropInvalid rule in the NEW rules section, or even before any of the rules listed in fw2vpn and vpn2fw (and the like) chains, do you think an invalid packet will ever make it to Drop/Reject let alone to dropInvalid in Drop/Reject? If not, why is dropInvlaid needed there then, when another, more appropriate place for it would be before those chains - and you still "won''t have to answer silly questions" if that were the case. ------------------------------------------------------------------------------ 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
On 6/2/11 3:01 PM, Mr Dash Four wrote:> >> If it is subject to a net->fw rule, then certainly no local program >> created it. >> > You know very well that is not the case here.Your statement about local programs was directly under a paragraph where I described net->fw INVALID packets, so I assumed that your comments were addressing that scenario.> >>> 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. >> > Answer me this then: If there is dropInvalid rule in the NEW rules > section, or even before any of the rules listed in fw2vpn and vpn2fw > (and the like) chains, do you think an invalid packet will ever make it > to Drop/Reject let alone to dropInvalid in Drop/Reject? If not, why is > dropInvlaid needed there then, when another, more appropriate place for > it would be before those chains - and you still "won''t have to answer > silly questions" if that were the case. >I''ve already explained why Shorewall must pass INVALID packets through the rules chain (initial installation). In addition, some users set /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose to provide "connection pickup". If INVALID packets were dropped early, that wouldn''t work. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 6/2/11 4:21 PM, Tom Eastep wrote:> > I''ve already explained why Shorewall must pass INVALID packets through > the rules chain (initial installation). In addition, some users set > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose to provide > "connection pickup". If INVALID packets were dropped early, that > wouldn''t work.And before you ask, connection pickup is described at http://security.maruhn.com/iptables-tutorial/x4436.html -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> I''ve already explained why Shorewall must pass INVALID packets through > the rules chain (initial installation). In addition, some users set > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose to provide > "connection pickup". If INVALID packets were dropped early, that > wouldn''t work. >So, if I follow your advice and add dropInvalid in the NEW section of my rules file I will be royally screwed too, is that it? As for whether SELinux is preventing sending of packets - the packets are indeed prevented from being sent, though they traverse through (at least) the NEW section of the rules file. Similarly, when packets are received they do appear in the corresponding section in rules, but they are never received by the process expecting these - SELinux prevents that too. ------------------------------------------------------------------------------ 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
On 6/2/11 6:44 PM, Mr Dash Four wrote:> >> I''ve already explained why Shorewall must pass INVALID packets through >> the rules chain (initial installation). In addition, some users set >> /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose to provide >> "connection pickup". If INVALID packets were dropped early, that >> wouldn''t work. >> > So, if I follow your advice and add dropInvalid in the NEW section of my > rules file I will be royally screwed too, is that it?Huh? -- 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 \________________________________________________ ------------------------------------------------------------------------------ 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
>>> I''ve already explained why Shorewall must pass INVALID packets through >>> the rules chain (initial installation). In addition, some users set >>> /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose to provide >>> "connection pickup". If INVALID packets were dropped early, that >>> wouldn''t work. >>> >>> >> So, if I follow your advice and add dropInvalid in the NEW section of my >> rules file I will be royally screwed too, is that it? >> > > Huh? >If I follow your advice and place dropInvalid at the start of my NEW section in rules, then I will prevent shorewall from "passing INVALID packets through the rules chain (initial installation)" so I will be screwed too, in which case what you suggested earlier can''t be taken as a viable solution. ------------------------------------------------------------------------------ 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
On 06/03/2011 04:42 AM, Mr Dash Four wrote:> >>>> I''ve already explained why Shorewall must pass INVALID packets through >>>> the rules chain (initial installation). In addition, some users set >>>> /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_loose to provide >>>> "connection pickup". If INVALID packets were dropped early, that >>>> wouldn''t work. >>>> >>> So, if I follow your advice and add dropInvalid in the NEW section of my >>> rules file I will be royally screwed too, is that it? >>> >> >> Huh? >> > If I follow your advice and place dropInvalid at the start of my NEW > section in rules, then I will prevent shorewall from "passing INVALID > packets through the rules chain (initial installation)" so I will be > screwed too, in which case what you suggested earlier can''t be taken as > a viable solution.It''s perfectly safe to add to a system on which Shorewall was started at boot. I run with a ''dropInvalid net all'' rule on my own firewall (it''s the first entry in my rules file). On Debian, at least, the default setting of /proc/sys/net/netfilter/nf_conntrack_tcp_loose is ''1'', so all->net INVALID state packets will create a conntrack entry which will then match incoming packets that are part of the same connection. That is the principle of ''connection pickup''. Note that stream-oriented protocols like TCP are the only ones where ''INVALID'' state can occur; it cannot occur on datagram-oriented protocols like UDP. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
On 06/03/2011 07:00 AM, Tom Eastep wrote:> It''s perfectly safe to add to a system on which Shorewall was started at > boot. I run with a ''dropInvalid net all'' rule on my own firewall > (it''s the first entry in my rules file). On Debian, at least, the > default setting of /proc/sys/net/netfilter/nf_conntrack_tcp_loose is > ''1'', so all->net INVALID state packets will create a conntrack entry > which will then match incoming packets that are part of the same > connection. That is the principle of ''connection pickup''. Note that > stream-oriented protocols like TCP are the only ones where ''INVALID'' > state can occur; it cannot occur on datagram-oriented protocols like UDP.One other thing that I should mention is that I have this in my /etc/shorewall/init file: echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal That turns off Netfilter''s window tracking feature which seems to continually have issues with correctly classifying packets. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> It''s perfectly safe to add to a system on which Shorewall was started at > boot. I run with a ''dropInvalid net all'' rule on my own firewall > (it''s the first entry in my rules file). On Debian, at least, the > default setting of /proc/sys/net/netfilter/nf_conntrack_tcp_loose is > ''1'', so all->net INVALID state packets will create a conntrack entry > which will then match incoming packets that are part of the same > connection. That is the principle of ''connection pickup''. Note that > stream-oriented protocols like TCP are the only ones where ''INVALID'' > state can occur; it cannot occur on datagram-oriented protocols like UDP. >The way I see it, this should be the very first thing done by shorewall - both for incoming as well as outgoing packets. OK, I understand the case for it to be optional (it may not be suitable in some rare circumstances - fair enough), but the option should be there without the need for me (i.e. the end-user) to add a pair of rules in every possible xx2fw and fw2xx combination. In other words, why not add it as an option in the interfaces - if it is there (say as part of the tunX line in interfaces) insert the appropriate dropInvalid rules - in both directions - at the very top of their corresponding chains? Better still, make it as shorewall.conf option and insert just one rule - at the top of OUTPUT and/or INPUT chains and be done with it - no need for messing about with rules and permutations and ask end-users to do this and that to "fix" it. Unfortunately I am unable to properly verify your ":(N)I" patches as I discovered a serious flaw on my testing harness last night (thanks in no small part to your patch btw) and will have to spend the weekend to fix that before I get to your patches. They look good and *should* be OK as the only thing your patches change is the addition of the "INVALID" state in the chain statements, which isn''t really something likely to cause any issues, but that''s me thinking and I am no expert. ------------------------------------------------------------------------------ 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
On 06/03/2011 08:00 AM, Mr Dash Four wrote:>> > The way I see it, this should be the very first thing done by shorewall > - both for incoming as well as outgoing packets. > > OK, I understand the case for it to be optional (it may not be suitable > in some rare circumstances - fair enough), but the option should be > there without the need for me (i.e. the end-user) to add a pair of rules > in every possible xx2fw and fw2xx combination. In other words, why not > add it as an option in the interfaces - if it is there (say as part of > the tunX line in interfaces) insert the appropriate dropInvalid rules - > in both directions - at the very top of their corresponding chains? > > Better still, make it as shorewall.conf option and insert just one rule > - at the top of OUTPUT and/or INPUT chains and be done with it - no need > for messing about with rules and permutations and ask end-users to do > this and that to "fix" it.A couple of points: a) It is silly to do INVALID filtering in the OUTPUT chain. If any INVALID packets show up there, then either the IP stack or Netfilter connection tracking is broken. And given the history, I would bet that it is the latter which is broken and that the packet should be sent regardless of what Netfilter thinks. b) It is hardly onerous to be required to place this rule at the top of the NEW section of your rules file when you want ingress INVALID filtering: dropInvalid all- all and you can log the dropped packets if you like: dropInvalid:info all- all and you can audit the dropped packets if you like: dropInvalid(audit) all- all c) If you want finer-grained control, it''s available by changing ''all-'' (all zones except the firewall) to something finer (''net'', ''net:eth0'', etc.). So having any additional controls doesn''t seem to buy anything and it costs my time.> > Unfortunately I am unable to properly verify your ":(N)I" patches as I > discovered a serious flaw on my testing harness last night (thanks in no > small part to your patch btw) and will have to spend the weekend to fix > that before I get to your patches. They look good and *should* be OK as > the only thing your patches change is the addition of the "INVALID" > state in the chain statements, which isn''t really something likely to > cause any issues, but that''s me thinking and I am no expert.It should be pretty foolproof. -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 \________________________________________________ ------------------------------------------------------------------------------ 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
> So having any additional controls doesn''t seem to buy anything and it > costs my time. >I''ve slightly modified b) and added "dropInvalid(audit) all all" instead - it seems to work, though I also had to remove the (now redundant) dropInvalid in action.Drop and action.Reject (no point in them being there now). It works OK so far.>> Unfortunately I am unable to properly verify your ":(N)I" patches as I >> discovered a serious flaw on my testing harness last night (thanks in no >> small part to your patch btw) and will have to spend the weekend to fix >> that before I get to your patches. They look good and *should* be OK as >> the only thing your patches change is the addition of the "INVALID" >> state in the chain statements, which isn''t really something likely to >> cause any issues, but that''s me thinking and I am no expert. >> > > It should be pretty foolproof. >Yep, it works - I''ve designed a small program to force generating "invalid" packets and send them over the wire - the firewall and the audit daemon catches them now. ------------------------------------------------------------------------------ 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