As part of the security policy I am writing I need to use the above 2 options with iptables, but I am not sure whether they are supported in Shorewall. Typically, I will add secure context marking to ip packets with the following statement: iptables -t mangle -A INPUT -p tcp --dst 127.0.0.1 --dport 3306 -j SECMARK --selctx system_u:object_r:mysqld_t:s0 This marks all packets to 127.0.0.1:3306 to be market with the ''system_u:object_r:mysqld_t:s0'' SELinux context. Does Shorewall provide a better way of handling this as I am not very keen on writing ''raw'' statements and maintenance will be an absolute nightmare? Thanks in advance! ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/4/10 10:34 AM, Mr Dash Four wrote:> As part of the security policy I am writing I need to use the above 2 > options with iptables, but I am not sure whether they are supported in > Shorewall. > > Typically, I will add secure context marking to ip packets with the > following statement: > > iptables -t mangle -A INPUT -p tcp --dst 127.0.0.1 --dport 3306 -j > SECMARK --selctx system_u:object_r:mysqld_t:s0 > > This marks all packets to 127.0.0.1:3306 to be market with the > ''system_u:object_r:mysqld_t:s0'' SELinux context. Does Shorewall provide > a better way of handling this as I am not very keen on writing ''raw'' > statements and maintenance will be an absolute nightmare?Shorewall does not currently support the SECMARK and CONNSECMARK targets. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Shorewall does not currently support the SECMARK and CONNSECMARK targets. >Are there any plans to introduce these in Shorewall? I see one suggestion I have made about 3 months ago (blacklists to include both outgoing and incoming connections) has been implemented in the latest version of Shorewall, what are the chances that SECMARK and CONNSECMARK will see the light of day in the Shorewall domain? ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/4/10 11:23 AM, Mr Dash Four wrote:> >> Shorewall does not currently support the SECMARK and CONNSECMARK targets. >> > Are there any plans to introduce these in Shorewall? > > I see one suggestion I have made about 3 months ago (blacklists to > include both outgoing and incoming connections) has been implemented in > the latest version of Shorewall, what are the chances that SECMARK and > CONNSECMARK will see the light of day in the Shorewall domain?I''ll see what I can do for the next beta release if you would be willing to test it. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> I''ll see what I can do for the next beta release if you would be willing > to test it. >I am, definitely! Shorewall, together with ipsets and now SECMARK/CONNSECMARK are going to be extensively used on 2 different platforms (x86 and x86_64 based), so plenty of scope for testing here! Just let me know and I''ll be ready Tom! P.S. I don''t know why, but this is the 2nd message from you today, which arrived in my Spam folder instead of my Inbox! ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
Hi, Tom, My init file (/etc/shorewall/init) is no longer executed at Shorewall startup. Is this intentional? If so, can this be corrected as I am using it to load my ifb0 interface as well as all of my ipsets (over 18K nets automatically compiled from a script using the ip-to-country database)! Without this Shorewall refuses to start. Also, the rc script provided in the beta package fails silently, so I had to use the one from the previous version (when I have the time I will merge the differences as there are things I could use in the beta version) to see what is wrong. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 9:18 AM, Mr Dash Four wrote:> Hi, Tom, > > > My init file (/etc/shorewall/init) is no longer executed at Shorewall > startup. Is this intentional?No -- but there is no reason that it would not be executed.> If so, can this be corrected as I am using it to load my ifb0 interface > as well as all of my ipsets (over 18K nets automatically compiled from a > script using the ip-to-country database)! > Without this Shorewall refuses to start.Please send me the /var/lib/shorewall/.start file.> Also, the rc script provided in > the beta package fails silently, so I had to use the one from the > previous version (when I have the time I will merge the differences as > there are things I could use in the beta version) to see what is wrong. >If you are normally using Yum to install, you are getting a script that is tailored for Fedora; the one I provide in the RPM from shorewall.net is a generic one. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
Hi, Tom, Further to my previous post, I managed to load my ipsets manually (through a shell script), but shorewall still refuses to start and I get the following error: ERROR: An ipset name (+blacklist-chinese-banned) is not allowed in this context: /etc/shorewall/blacklist (line 11) The line in question in my blacklist file contains this: +blacklist-chinese-banned - - to There are about 8 lines similar to this, though the above is the first one. What''s wrong? I had this working before, though I adopted the new syntax (with the ''to''/''from'' options) and changed to the above format. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 9:32 AM, Mr Dash Four wrote:> Hi, Tom, > > > Further to my previous post, I managed to load my ipsets manually > (through a shell script), but shorewall still refuses to start and I get > the following error: > > ERROR: An ipset name (+blacklist-chinese-banned) is not allowed in this > context: /etc/shorewall/blacklist (line 11) > > The line in question in my blacklist file contains this: > > +blacklist-chinese-banned - - to > > > There are about 8 lines similar to this, though the above is the first > one. What''s wrong? I had this working before, though I adopted the new > syntax (with the ''to''/''from'' options) and changed to the above format.Please: 1) shorewall show -f capabilities > /etc/shorewall/caps 2) tar -zcf shorewall.tgz /etc/shorewall 3) Send me the shorewall.tgz file 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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 9:32 AM, Mr Dash Four wrote:> Hi, Tom, > > > Further to my previous post, I managed to load my ipsets manually > (through a shell script), but shorewall still refuses to start and I get > the following error: > > ERROR: An ipset name (+blacklist-chinese-banned) is not allowed in this > context: /etc/shorewall/blacklist (line 11) > > The line in question in my blacklist file contains this: > > +blacklist-chinese-banned - - to > > > There are about 8 lines similar to this, though the above is the first > one. What''s wrong? I had this working before, though I adopted the new > syntax (with the ''to''/''from'' options) and changed to the above format.Also -- what version of Shorewall were you running previously? -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 9:32 AM, Mr Dash Four wrote:> Hi, Tom, > > > Further to my previous post, I managed to load my ipsets manually > (through a shell script), but shorewall still refuses to start and I get > the following error: > > ERROR: An ipset name (+blacklist-chinese-banned) is not allowed in this > context: /etc/shorewall/blacklist (line 11) > > The line in question in my blacklist file contains this: > > +blacklist-chinese-banned - - to > > > There are about 8 lines similar to this, though the above is the first > one. What''s wrong? I had this working before, though I adopted the new > syntax (with the ''to''/''from'' options) and changed to the above format.A line like that works fine for me. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Also -- what version of Shorewall were you running previously? >The last one coming from the standard fedora/update repository - 4.4.11.1 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 10:03 AM, Mr Dash Four wrote:> >> Please: >> >> 1) shorewall show -f capabilities > /etc/shorewall/caps >> 2) tar -zcf shorewall.tgz /etc/shorewall >> 3) Send me the shorewall.tgz file >> > Done, see attached. >Beginning with Shorewall 4.4.0, ipset names cannot contain "-". -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 10:12 AM, Tom Eastep wrote:> On 9/5/10 10:03 AM, Mr Dash Four wrote: >> >>> Please: >>> >>> 1) shorewall show -f capabilities > /etc/shorewall/caps >>> 2) tar -zcf shorewall.tgz /etc/shorewall >>> 3) Send me the shorewall.tgz file >>> >> Done, see attached. >> > > Beginning with Shorewall 4.4.0, ipset names cannot contain "-".Although that was only recently enforced. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Beginning with Shorewall 4.4.0, ipset names cannot contain "-". >My previous (and working) version was 4.4.11.1 and it contained those same names including "-"! ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> A line like that works fine for me. >What version are you using? ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Although that was only recently enforced. >Why is my Shorewall init script not executed (this, as I pointed out, only happens with this beta)? Any ideas? ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 10:24 AM, Mr Dash Four wrote:> >> Although that was only recently enforced. >> > Why is my Shorewall init script not executed (this, as I pointed out, > only happens with this beta)? Any ideas?None -- that''s why I asked you to send me the /var/lib/shorewall/.start file (or /var/lib/shorewall/firewall, if ''start'' is successful). -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 10:17 AM, Mr Dash Four wrote:> >> Beginning with Shorewall 4.4.0, ipset names cannot contain "-". >> > My previous (and working) version was 4.4.11.1 and it contained those > same names including "-"! >Here''s a patch that allows ''-''. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 10:50 AM, Tom Eastep wrote:> On 9/5/10 10:17 AM, Mr Dash Four wrote: >> >>> Beginning with Shorewall 4.4.0, ipset names cannot contain "-". >>> >> My previous (and working) version was 4.4.11.1 and it contained those >> same names including "-"! >> > > Here''s a patch that allows ''-''.Note that this one is against /usr/share/shorewall/Shorewall/Chains.pm rather than /usr/share/shorewall/Shorewall/Tc.pm -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Here''s a patch that allows ''-''. >Thanks for that, though I have just replaced all occurrences of "-" with "_", then manually loaded the init file and executed shorewall - it was OK this time and without errors, though I am baffled by something else - I expected to see the "blacklst" chain to appear in my fw2net so that it blocks "blacklisted" packets FROM my machine, but my fw2net is clear of such thing. There is no reference to blacklst there! The blacklst chain itself contains the "src" and "dst" match-set statements as expected, but how are my packets FROM my FW to the "blacklisted" addresses banned? Or are they?! Or is it that I am missing something with the new format? ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Note that this one is against /usr/share/shorewall/Shorewall/Chains.pm > rather than /usr/share/shorewall/Shorewall/Tc.pm >Noted! ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 10:58 AM, Mr Dash Four wrote:> >> Here''s a patch that allows ''-''. >> > Thanks for that, though I have just replaced all occurrences of "-" with > "_", then manually loaded the init file and executed shorewall - it was > OK this time and without errors, though I am baffled by something else - > I expected to see the "blacklst" chain to appear in my fw2net so that it > blocks "blacklisted" packets FROM my machine, but my fw2net is clear of > such thing. There is no reference to blacklst there! > > The blacklst chain itself contains the "src" and "dst" match-set > statements as expected, but how are my packets FROM my FW to the > "blacklisted" addresses banned? Or are they?! Or is it that I am missing > something with the new format? >The ''to'' option does not work from the firewall itself. As stated in the release notes where the feature was introduced, the blacklist is still applied on packets arriving on ''blacklist'' interfaces. -Topm -- 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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 11:04 AM, Tom Eastep wrote:> On 9/5/10 10:58 AM, Mr Dash Four wrote: >> >>> Here''s a patch that allows ''-''. >>> >> Thanks for that, though I have just replaced all occurrences of "-" with >> "_", then manually loaded the init file and executed shorewall - it was >> OK this time and without errors, though I am baffled by something else - >> I expected to see the "blacklst" chain to appear in my fw2net so that it >> blocks "blacklisted" packets FROM my machine, but my fw2net is clear of >> such thing. There is no reference to blacklst there! >> >> The blacklst chain itself contains the "src" and "dst" match-set >> statements as expected, but how are my packets FROM my FW to the >> "blacklisted" addresses banned? Or are they?! Or is it that I am missing >> something with the new format? >> > > The ''to'' option does not work from the firewall itself. As stated in the > release notes where the feature was introduced, the blacklist is still > applied on packets arriving on ''blacklist'' interfaces.The shorewall-blacklist man page also makes this point. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> The ''to'' option does not work from the firewall itself. As stated in the > release notes where the feature was introduced, the blacklist is still > applied on packets arriving on ''blacklist'' interfaces. >In other words this new blacklist format does not stop packets FROM my interface (even if the ''blacklist'' option is used) to "blacklisted" addresses, is that right? If so, then I need to restore my old DROP statements I''ve had in the rules file and remove half of the statements currently in my blacklist file. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> The shorewall-blacklist man page also makes this point. >It says on the man page that the to/from option "indicates whether traffic to or from the ADDRESS/SUBNET should be blacklisted" - that, to me, clearly says that bidirectional traffic on my interface should be blacklisted, right? In my simple scenario I only have one interface, and it has the blacklist option set in it, so presumably traffic TO blacklisted addresses (originating from my machine) as well as coming FROM blacklisted addresses (and addressed to my machine) should both be blacklisted, right? If so, should I expect to see a reference to ''blacklst'' in my fw2net chain? ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 11:15 AM, Mr Dash Four wrote:> >> The ''to'' option does not work from the firewall itself. As stated in the >> release notes where the feature was introduced, the blacklist is still >> applied on packets arriving on ''blacklist'' interfaces. >> > In other words this new blacklist format does not stop packets FROM my > interface (even if the ''blacklist'' option is used) to "blacklisted" > addresses, is that right? If so, then I need to restore my old DROP > statements I''ve had in the rules file and remove half of the statements > currently in my blacklist file. >I guess I''m baffled as to why a firewall needs to have an outgoing blacklist. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 11:22 AM, Mr Dash Four wrote:> >> The shorewall-blacklist man page also makes this point. >> > It says on the man page that the to/from option "indicates whether > traffic to or from the ADDRESS/SUBNET should be blacklisted" - that, to > me, clearly says that bidirectional traffic on my interface should be > blacklisted, right? In my simple scenario I only have one interface, and > it has the blacklist option set in it, so presumably traffic TO > blacklisted addresses (originating from my machine) as well as coming > FROM blacklisted addresses (and addressed to my machine) should both be > blacklisted, right? If so, should I expect to see a reference to > ''blacklst'' in my fw2net chain?You can''t just read what you want to read and ignore the rest. The man page goes on to say: Note: Blacklisting is still restricted to traffic arriving on an interface that has the ´blacklist´ option set. So to block traffic from your local network to an internet host, you must specify blacklist on your internal interface in shorewall-interfaces[1] (5). You should not expect to see a reference to ''blacklist'' in your fw2net chain since such traffic could not possibly have arrived on an interface that has the ''blacklist'' option set. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> I guess I''m baffled as to why a firewall needs to have an outgoing > blacklist. >Simple scenario - say I use p2p-type program (like azureus or something) or, worse still, have a rogue code/process/program on my machine (that I know nothing of) which tries to communicate from my machine to IP addresses which are banned (i.e. try to "call home") - in that case I would need these packets to be dropped without question. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> You can''t just read what you want to read and ignore the rest. The man > page goes on to say: > > Note: Blacklisting is still restricted to traffic arriving on an > interface that has the ´blacklist´ option set. So to block traffic from > your local network to an internet host, you must specify blacklist on > your internal interface in shorewall-interfaces[1] (5). > > You should not expect to see a reference to ''blacklist'' in your fw2net > chain since such traffic could not possibly have arrived on an interface > that has the ''blacklist'' option set. >OK, simple question then (as we screwed away from the SECMARK business, which is what this thread was supposed to be discussing) - provided I use the statements you know about in my blacklist file would that block traffic originating FROM my machine to these blacklisted addresses? Yes or No? ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 11:38 AM, Mr Dash Four wrote:> >> I guess I''m baffled as to why a firewall needs to have an outgoing >> blacklist. >> > Simple scenario - say I use p2p-type program (like azureus or something) > or, worse still, have a rogue code/process/program on my machine (that I > know nothing of) which tries to communicate from my machine to IP > addresses which are banned (i.e. try to "call home") - in that case I > would need these packets to be dropped without question. >So this isn''t really a firewall -- it''s a host that happens to run Shorewall. That is not a use case that I target with Shorewall, although Shorewall can be used there. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 11:43 AM, Mr Dash Four wrote:> >> You can''t just read what you want to read and ignore the rest. The man >> page goes on to say: >> >> Note: Blacklisting is still restricted to traffic arriving on an >> interface that has the ´blacklist´ option set. So to block traffic from >> your local network to an internet host, you must specify blacklist on >> your internal interface in shorewall-interfaces[1] (5). >> >> You should not expect to see a reference to ''blacklist'' in your fw2net >> chain since such traffic could not possibly have arrived on an interface >> that has the ''blacklist'' option set. >> > OK, simple question then (as we screwed away from the SECMARK business, > which is what this thread was supposed to be discussing) - provided I > use the statements you know about in my blacklist file would that block > traffic originating FROM my machine to these blacklisted addresses? Yes > or No?No -- nor was it intended to. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> > So this isn''t really a firewall -- it''s a host that happens to run > Shorewall. That is not a use case that I target with Shorewall, although > Shorewall can be used there. >It won''t make a big difference whether this rogue code executes on a single host ''that happens to run Shorewall'' or if it resides on a firewall with 3+ different interfaces, controlling 3+ different networks - that traffic (initiated from the rogue code) still originates from that machine and is destined to the outside world. Anyway, this is all academical now - in my case I am reverting to the old format as this is how traffic originating from that machine to rogue IP addresses can be dropped. I was hoping that with the new syntax I won''t need to include DROP fw2net rules in my rules file, but that is not the case. No worries, thanks for clarifying. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/5/10 12:00 PM, Mr Dash Four wrote:> >> >> So this isn''t really a firewall -- it''s a host that happens to run >> Shorewall. That is not a use case that I target with Shorewall, although >> Shorewall can be used there. >> > It won''t make a big difference whether this rogue code executes on a > single host ''that happens to run Shorewall'' or if it resides on a > firewall with 3+ different interfaces, controlling 3+ different networks > - that traffic (initiated from the rogue code) still originates from > that machine and is destined to the outside world.If there are no applications running on the firewall, then the fw->net ruleset can be very restricted; no outgoing blacklist is necessary. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Shorewall does not currently support the SECMARK and CONNSECMARK targets. >A few quick observations and queries. I have successfully tested a straight-forward SECMARKs setup (labelling my sshd, mysqld and openvpn traffic) without a glitch. I am now in a position to start testing more complex setups, though I ran into a bit of difficulty. For example - I want to label traffic, which is initiated by a specific process and starts from an arbitrary random high port and is also destined to an arbitrary random high port on a network (not a specific IP address). In my rules file I restricted such traffic by User ID/Group ID and that did the job as this process runs in confined environment under the restrictions of UID/GID (and SELinux). As it stands though, the secmarks file won''t allow me to use this approach and add User ID/Group ID as I am able to with my rules file. Would that be possible - could this be added as an option? If not, any advice as to how to label such traffic (add a specific chain perhaps?) would be welcome. A question may be related to the above - the purpose of CONNSECMARK is to ''save'' a packet mark to a specific connection (normally used when a connection is setup) or ''restore'' a connection label to a packet (normally for all subsequent packets on that connection), though I am not entirely sure how would I use this with the SAVE and RESTORE commands and to which chains I should apply those. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/6/10 6:38 AM, Mr Dash Four wrote:> >> Shorewall does not currently support the SECMARK and CONNSECMARK targets. >> > A few quick observations and queries. I have successfully tested a > straight-forward SECMARKs setup (labelling my sshd, mysqld and openvpn > traffic) without a glitch. > > I am now in a position to start testing more complex setups, though I > ran into a bit of difficulty. > > For example - I want to label traffic, which is initiated by a specific > process and starts from an arbitrary random high port and is also > destined to an arbitrary random high port on a network (not a specific > IP address). In my rules file I restricted such traffic by User ID/Group > ID and that did the job as this process runs in confined environment > under the restrictions of UID/GID (and SELinux). > > As it stands though, the secmarks file won''t allow me to use this > approach and add User ID/Group ID as I am able to with my rules file. > Would that be possible - could this be added as an option? If not, any > advice as to how to label such traffic (add a specific chain perhaps?) > would be welcome.Your requirements were incompletely given then. I''ll send you another RPM privately that will include that support.> > A question may be related to the above - the purpose of CONNSECMARK is > to ''save'' a packet mark to a specific connection (normally used when a > connection is setup) or ''restore'' a connection label to a packet > (normally for all subsequent packets on that connection), though I am > not entirely sure how would I use this with the SAVE and RESTORE > commands and to which chains I should apply those.Please look at the example in the manpage from the updated RPM; hopefully, it will make this clearer. You might also consult the SELinux documentation about how to use the CONNSECMARK target. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Please look at the example in the manpage from the updated RPM; > hopefully, it will make this clearer. You might also consult the SELinux > documentation about how to use the CONNSECMARK target. >Superb example and is exactly what I needed! Thank you! I am off to do some testing. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Please look at the example in the manpage from the updated RPM; > hopefully, it will make this clearer. You might also consult the SELinux > documentation about how to use the CONNSECMARK target. >My observations after applying the latest changes (I''ll start with the bugs): 1. When I put "system_u:object_r:voip_sandbox_packet_t:s0 I:N eth1:212.12.176.12 - tcp 8006 - root" for example this compiles to and produces "-A tcin -m conntrack --ctstate NEW -p 6 --dport 8006 -m owner --uid-owner root -i eth1 -s 212.12.176.12 -j SECMARK --selctx system_u:object_r:voip_sandbox_packet_t:s0", which, when executed with iptables gives me the following error: "kernel: ip_tables: owner match: used from hooks INPUT, but only valid from OUTPUT/POSTROUTING". I presume the same rules apply as in the /etc/shorewall/rules, i.e. NO UID/GID in the incoming chains (net->fw for example), so this needs to be corrected. 2. Currently there is no ability to add comments in secmarks - it would be nice if I could do that as is the case with the rules file (I am not sure if the Shorewall adds comments automatically in secmarks as is the case with the rules file - when common port numbers are used for example). 3. The example given in shorewall-secmarks uses SELinux type "mysqld_t", which even though works, it WILL fail when this is run for the simple reason that this type is already defined and it does not contain the appropriate SELinux attributes ("packet_type", "server_packet_type" or "client_packet_type"). Type "mysqld_t" is dedicated to the MySQL Daemon domain - not its packets. The appropriate type to use in the example given would be something like "mysqld_packet_t", so the appropriate security context for mysqld packets would therefore be "system_u:object_r:mysqld_packet_t:s0". 4. CONNSECMARK - that was a true eye opener for me!!! Having now examined, in great detail, how this mechanism works and then seeing it in action I am well-pleased I took the time to learn about this, because it makes a huge amount of difference - both from a point of view of security as well as performance. I am also ready to make a few suggestions for "optimisation" of Shorewall in this regard. The SAVE command, in vast majority of cases, makes sense to be executed LAST in the NEW packets chain and WITHOUT any additional restrictions, i.e. "SAVE I:N" or "SAVE O:N". This would save any SELinux context for which there was a match in the previous secmarks statements for this chain type. So, if that is the case, why not integrate it with the optimisation mechanism which exist in Shorewall - it could be specified to be included as an end statement of each chain in the NEW section without being explicitly declared in the secmarks file. Exactly the same would apply for RESTORE as well, but with ESTABLISHED and RELATED type packets. The reason I am pushing for this is because I just experienced first hand what impact this mechanism has, particularly on performance - I used it to push VOIP traffic to an external server and with SAVE/RESTORE it is faster - a lot faster! Not to mention that I do not need to worry about security implications as that is not an issue any more - connections are tracked and SELinux contexts are re-established ''automatically'' so to speak. 5. Just a direction of thought for now - I am a bit uncomfortable with the "CHAIN" column in secmarks - it would be nice if the secmarks file could be adapted to have sections in the same way as is in the rules file (like SECTION NEW, SECTION ESTABLISHED etc) - it would make it more consistent. Don''t know whether that would be possible though. 6. Finally, two minor bits, which I am sure will be ironed out by the time the new version of Shorewall is released - it would be good to have a ''sample'' secmarks file in the distribution and all man-pages (except shorewall-secmarks) need to reference shorewall-secmarks as is done with all the other sections of the manual. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/6/10 3:28 PM, Mr Dash Four wrote:> >> Please look at the example in the manpage from the updated RPM; >> hopefully, it will make this clearer. You might also consult the SELinux >> documentation about how to use the CONNSECMARK target. >> > My observations after applying the latest changes (I''ll start with the > bugs): > > 1. When I put "system_u:object_r:voip_sandbox_packet_t:s0 I:N > eth1:212.12.176.12 - tcp 8006 - root" for example this compiles to and > produces "-A tcin -m conntrack --ctstate NEW -p 6 --dport 8006 -m owner > --uid-owner root -i eth1 -s 212.12.176.12 -j SECMARK --selctx > system_u:object_r:voip_sandbox_packet_t:s0", which, when executed with > iptables gives me the following error: "kernel: ip_tables: owner match: > used from hooks INPUT, but only valid from OUTPUT/POSTROUTING". > > I presume the same rules apply as in the /etc/shorewall/rules, i.e. NO > UID/GID in the incoming chains (net->fw for example), so this needs to > be corrected.Done.> > 2. Currently there is no ability to add comments in secmarks - it would > be nice if I could do that as is the case with the rules file (I am not > sure if the Shorewall adds comments automatically in secmarks as is the > case with the rules file - when common port numbers are used for example).COMMENT is supported in the secmarks file. See http://www.shorewall.net/configuration_file_basics.html#COMMENT> > 3. The example given in shorewall-secmarks uses SELinux type "mysqld_t", > which even though works, it WILL fail when this is run for the simple > reason that this type is already defined and it does not contain the > appropriate SELinux attributes ("packet_type", "server_packet_type" or > "client_packet_type"). Type "mysqld_t" is dedicated to the MySQL Daemon > domain - not its packets. The appropriate type to use in the example > given would be something like "mysqld_packet_t", so the appropriate > security context for mysqld packets would therefore be > "system_u:object_r:mysqld_packet_t:s0".It was your example, not mine. See the post that started this thread. I know nothing about SELinux. But I''ve updated the manpages.> > 4. CONNSECMARK - that was a true eye opener for me!!! > > Having now examined, in great detail, how this mechanism works and then > seeing it in action I am well-pleased I took the time to learn about > this, because it makes a huge amount of difference - both from a point > of view of security as well as performance. I am also ready to make a > few suggestions for "optimisation" of Shorewall in this regard. > > The SAVE command, in vast majority of cases, makes sense to be executed > LAST in the NEW packets chain and WITHOUT any additional restrictions, > i.e. "SAVE I:N" or "SAVE O:N". This would save any SELinux context for > which there was a match in the previous secmarks statements for this > chain type. So, if that is the case, why not integrate it with the > optimisation mechanism which exist in Shorewall - it could be specified > to be included as an end statement of each chain in the NEW section > without being explicitly declared in the secmarks file. > > Exactly the same would apply for RESTORE as well, but with ESTABLISHED > and RELATED type packets. > > The reason I am pushing for this is because I just experienced first > hand what impact this mechanism has, particularly on performance - I > used it to push VOIP traffic to an external server and with SAVE/RESTORE > it is faster - a lot faster! Not to mention that I do not need to worry > about security implications as that is not an issue any more - > connections are tracked and SELinux contexts are re-established > ''automatically'' so to speak.So exactly what are you pushing for?> 5. Just a direction of thought for now - I am a bit uncomfortable with > the "CHAIN" column in secmarks - it would be nice if the secmarks file > could be adapted to have sections in the same way as is in the rules > file (like SECTION NEW, SECTION ESTABLISHED etc) - it would make it more > consistent. Don''t know whether that would be possible though.It''s possible but it''s not going to happen.> > 6. Finally, two minor bits, which I am sure will be ironed out by the > time the new version of Shorewall is released - it would be good to have > a ''sample'' secmarks file in the distribution and all man-pages (except > shorewall-secmarks) need to reference shorewall-secmarks as is done with > all the other sections of the manual.That''s not going to happen either. <rant> This is basically a one-man project. I get excellent help from a group of people that produce packages for various distributions and that help with support. But I produce almost all of the code and documentation. And writing code is about 20% of my time spent on Shorewall; the rest is support, writing documentation, and answering posts like yours. </rant> -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> Done. >Do you have a patch or new rpm for me to test?>> 2. Currently there is no ability to add comments in secmarks - it would >> be nice if I could do that as is the case with the rules file (I am not >> sure if the Shorewall adds comments automatically in secmarks as is the >> case with the rules file - when common port numbers are used for example). >> > > COMMENT is supported in the secmarks file. See > http://www.shorewall.net/configuration_file_basics.html#COMMENT >That link is getting me nowhere! I presume you meant http://www.shorewall.net/configuration_file_basics.htm#Comments which isn''t what I really meant in my previous post, but this: COMMENT the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of "shorewall show <chain>". To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. In other words, COMMENT the command as is in the rules file - as pointed out in my previous post.>> 4. CONNSECMARK - that was a true eye opener for me!!! >> >> >> > So exactly what are you pushing for? >Instead of manually adding "SAVE I:N", "SAVE O:N" and then "RESTORE I:ER", "RESTORE O:ER" etc. at the end of each chain (as this would be the most efficient way of dealing with SELinux contexts once they are established) it would be nice if these things are ''optimised'' and added automatically by Shorewall when an appropriate option is turned on in shorewall.conf (like "AUTO_CONNSECMARK=Yes" for example) so that I do not have to put these manually. As I already pointed out - in vast majority of cases SAVE and RESTORE would make sense to be placed in the above form at the end of each chain so that they take care of preserving and restoring SELinux contexts in connections, so why not add them automatically?>> 6. Finally, two minor bits, which I am sure will be ironed out by the >> time the new version of Shorewall is released - it would be good to have >> a ''sample'' secmarks file in the distribution and all man-pages (except >> shorewall-secmarks) need to reference shorewall-secmarks as is done with >> all the other sections of the manual. >> > > That''s not going to happen either. >What isn''t going to happen - a new Shorewall version?! Sample files, more like templates really (like empty rules, interfaces and many other files) are provided as part of the Shorewall distribution, so I do not see why including an empty template secmarks file in the final Shorewall distribution is proving to be such a major headache? As for the man pages - at the end of each man page there is reference to all other shorewall-* man pages, so I thought it would make sense to include shorewall-secmarks in that list, that''s all. Don''t see why this is proving to be such a problem, but guessing by your rant below you couldn''t be arsed - fair enough.> <rant> This is basically a one-man project. I get excellent help from a > group of people that produce packages for various distributions and that > help with support. But I produce almost all of the code and > documentation. And writing code is about 20% of my time spent on > Shorewall; the rest is support, writing documentation, and answering > posts like yours. > </rant> >Your point being? Soon after I started this thread I agreed to do the testing of SECMARK and CONNSECMARK - a new set of features for YOUR Shorewall Beta4 - and provide YOU with feedback. This is precisely what I have been doing for the past couple of days (and yes, you are not the only one who is "spending time on Shorewall" and "answering posts"), so if you have a problem with that (or me for that matter) just let me know and you won''t need to "answer posts like mine" any more. Simple as really. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/7/10 4:43 AM, Mr Dash Four wrote:> >> Done. >> > Do you have a patch or new rpm for me to test?I''ll be releasing Beta-4 later in the week; you can test then.> >>> 2. Currently there is no ability to add comments in secmarks - it would >>> be nice if I could do that as is the case with the rules file (I am not >>> sure if the Shorewall adds comments automatically in secmarks as is the >>> case with the rules file - when common port numbers are used for example). >>> >> >> COMMENT is supported in the secmarks file. See >> http://www.shorewall.net/configuration_file_basics.html#COMMENTTypo in the link -- http://www.shorewall.net/configuration_file_basics.htm#COMMENT>> > That link is getting me nowhere! I presume you meant > http://www.shorewall.net/configuration_file_basics.htm#Comments which > isn''t what I really meant in my previous post, but this: > > COMMENT the rest of the line will be attached as a comment to the > Netfilter rule(s) generated by the following entries. The comment will > appear delimited by "/* ... */" in the output of "shorewall show > <chain>". To stop the comment from being attached to further rules, > simply include COMMENT on a line by itself. > > In other words, COMMENT the command as is in the rules file - as pointed > out in my previous post.Which is already implemented in the Alpha-level code that you have; I just haven''t gotten around to documenting it in the man pages yet.> >>> 4. CONNSECMARK - that was a true eye opener for me!!! >>> >>> >>> >> So exactly what are you pushing for? >> > Instead of manually adding "SAVE I:N", "SAVE O:N" and then "RESTORE > I:ER", "RESTORE O:ER" etc. at the end of each chain (as this would be > the most efficient way of dealing with SELinux contexts once they are > established) it would be nice if these things are ''optimised'' and added > automatically by Shorewall when an appropriate option is turned on in > shorewall.conf (like "AUTO_CONNSECMARK=Yes" for example) so that I do > not have to put these manually. > > As I already pointed out - in vast majority of cases SAVE and RESTORE > would make sense to be placed in the above form at the end of each chain > so that they take care of preserving and restoring SELinux contexts in > connections, so why not add them automatically?I try to avoid adding any ''Shorewall automatically assumes ....'' features because "The vast majority of cases" is not "All cases". In general, my approach with Shorewall has been flexibility, rather than "works is most cases". I will consider a shorewall.conf (shorewall6.conf) option as a follow-on enhancement, but given how much more popular tcrules are than secmarks, I would probably add the enhancement for tcrules first.> >>> 6. Finally, two minor bits, which I am sure will be ironed out by the >>> time the new version of Shorewall is released - it would be good to have >>> a ''sample'' secmarks file in the distribution and all man-pages (except >>> shorewall-secmarks) need to reference shorewall-secmarks as is done with >>> all the other sections of the manual. >>> >> >> That''s not going to happen either. >> > What isn''t going to happen - a new Shorewall version?! > > Sample files, more like templates really (like empty rules, interfaces > and many other files) are provided as part of the Shorewall > distribution, so I do not see why including an empty template secmarks > file in the final Shorewall distribution is proving to be such a major > headache?I misread your comment; sorry. There are already empty secmarks files in my source tree -- I just haven''t updated the installers to include them in the packages.> > As for the man pages - at the end of each man page there is reference to > all other shorewall-* man pages, so I thought it would make sense to > include shorewall-secmarks in that list, that''s all. Don''t see why this > is proving to be such a problem, but guessing by your rant below you > couldn''t be arsed - fair enough.Again, I''ll get around to it. Remember that what you are running is alpha level code.> > >> <rant> This is basically a one-man project. I get excellent help from a >> group of people that produce packages for various distributions and that >> help with support. But I produce almost all of the code and >> documentation. And writing code is about 20% of my time spent on >> Shorewall; the rest is support, writing documentation, and answering >> posts like yours. >> </rant> >> > Your point being? >I apologize for the rant -- I should have set your expectations when we started. I don''t run SELinux on any of my test environments and I have no time or interest to learn how Netfilter interacts with SELinux, except at the iptables command syntax level. I therefore needed someone to verify that the ruleset would actually load on a SELinux-enabled system and that the ruleset would do whatever it is intended to do. So I sent you the very first code that I produced in an effort to ensure that the iptables-restore input produced by Shorewall will actually load and work. I sent you a second RPM because the change you suggested to add a USER/GROUP column involved several files and would have been hard for you to install as a patch. My ill-conceived rant was my way of pointing out that getting code that works is only a small part of what is required to produce a complete and supportable product. There is a lot that needs to be done after the code apparently works before the product can be considered complete. So please bear with me; when Beta 4 is finally released, *then* please send me feedback about missing examples and incomplete documentation. Thanks, -Tom PS -- In my rant, I failed to mention that there also people who work tirelessly to test the Betas and RCs; they are also very much appreciated. -- 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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> I''ll be releasing Beta-4 later in the week; you can test then. >OK, just let me know.>> COMMENT the rest of the line will be attached as a comment to the >> Netfilter rule(s) generated by the following entries. The comment will >> appear delimited by "/* ... */" in the output of "shorewall show >> <chain>". To stop the comment from being attached to further rules, >> simply include COMMENT on a line by itself. >> >> In other words, COMMENT the command as is in the rules file - as pointed >> out in my previous post. >> > > Which is already implemented in the Alpha-level code that you have; I > just haven''t gotten around to documenting it in the man pages yet. >The rpm you last sent me (two days ago I think it was) did not work as this was one of the first things I tried (I do like this feature as it gives me an instant indication of ''my'' code when I look at the chains, rather than the generated stuff from iptables/Shorewall) - it gave me an error during compilation: insufficient number of columns/parameters or something.>> Instead of manually adding "SAVE I:N", "SAVE O:N" and then "RESTORE >> I:ER", "RESTORE O:ER" etc. at the end of each chain (as this would be >> the most efficient way of dealing with SELinux contexts once they are >> established) it would be nice if these things are ''optimised'' and added >> automatically by Shorewall when an appropriate option is turned on in >> shorewall.conf (like "AUTO_CONNSECMARK=Yes" for example) so that I do >> not have to put these manually. >> >> As I already pointed out - in vast majority of cases SAVE and RESTORE >> would make sense to be placed in the above form at the end of each chain >> so that they take care of preserving and restoring SELinux contexts in >> connections, so why not add them automatically? >> > > I try to avoid adding any ''Shorewall automatically assumes ....'' > features because "The vast majority of cases" is not "All cases". In > general, my approach with Shorewall has been flexibility, rather than > "works is most cases". >Flexibility indeed! Hence why I suggested that you could add an option (or include it as another optimisation level as you currently do with so many other things on Shorewall) and let Shorewall users decide what to use. Another reason for this is that mistakes with SAVE and RESTORE are *very* easy to make as I found out to my own cost (using SAVE "I:N"/"RESTORE I:ER" with attaching additional parameters - ports etc - which is an absolute rubbish thing to do!) - hence if I know that my network deploys SELinux (which is what I aim for really) and all network traffic is controlled I just switch this option on, Shorewall attaches SAVE/RESTORE statements at the end of each CHAIN ''automatically'' and the only thing I need to concentrate on, as far as secmarks are concerned, is defining the SELinux contexts for the traffic I am controlling. For others, who do not need/do not want to use this approach and prefer to do everything ''manually'' they can switch this option off and get on with it without additional hassle. Very much like the optimisation levels you have currently built in Shorewall. You don''t take anything away, on the contrary - you provide flexibility and keep everyone happy!> I will consider a shorewall.conf (shorewall6.conf) option as a follow-on > enhancement, but given how much more popular tcrules are than secmarks, > I would probably add the enhancement for tcrules first. >No worries, just expressing my opinion - the decision, ultimately, is for you to make, that''s all.> I apologize for the rant -- I should have set your expectations when we > started. I don''t run SELinux on any of my test environments and I have > no time or interest to learn how Netfilter interacts with SELinux, > except at the iptables command syntax level. I therefore needed someone > to verify that the ruleset would actually load on a SELinux-enabled > system and that the ruleset would do whatever it is intended to do.I am not SELinux expert myself either (as you''ve probably gathered by now!). In fact, up until about 3-4 months ago I was dead against deploying ''this monstrosity'' anywhere near production environment as the headaches of dealing with security alerts would have sucked the life out of me. An incident I''ve had coupled with an inspiration and all the valuable help I received from genuine experts on the SELinux user list turned me around and I am now seeing the benefits of deploying such system. It is well worth it and I would advice anyone interested in SELinux to invest and spend some time to learn about it! Anyway...> So I > sent you the very first code that I produced in an effort to ensure that > the iptables-restore input produced by Shorewall will actually load and > work. I sent you a second RPM because the change you suggested to add a > USER/GROUP column involved several files and would have been hard for > you to install as a patch. >The fix you''ve developed does its job, and even though there are a few ''rough edges'' the core of it is done, which was the main point of me starting this thread and doing the testing later on.> My ill-conceived rant was my way of pointing out that getting code that > works is only a small part of what is required to produce a complete and > supportable product. There is a lot that needs to be done after the code > apparently works before the product can be considered complete.I concur and it was never my intention to suggest otherwise! If it came out differently - well, it would be my turn to apologise!> So > please bear with me; when Beta 4 is finally released, *then* please send > me feedback about missing examples and incomplete documentation. >No worries, just let me know and I''ll give it a go again. ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/7/10 3:27 PM, Mr Dash Four wrote:> The rpm you last sent me (two days ago I think it was) did not work as > this was one of the first things I tried (I do like this feature as it > gives me an instant indication of ''my'' code when I look at the chains, > rather than the generated stuff from iptables/Shorewall) - it gave me an > error during compilation: insufficient number of columns/parameters or > something.That must not have been the second RPM I sent -- I just installed the second one (taken from my mailer''s ''sent'' log) on a SuSE box and tested with the following nonsense secmarks file: COMMENT foo a:b:c I:N lo 127.0.0.1 tcp 3306 COMMENT And it generated this iptables-restore input: -A tcin -m conntrack --ctstate NEW -p 6 --dport 3306 -i lo -d 127.0.0.1 -j SECMARK --selctx a:b:c -m comment --comment "foo"> No worries, just let me know and I''ll give it a go again.I would appreciate getting a copy of your finished secmarks configuration so I can include it as an example on the web site and in the document packages. 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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/7/10 3:27 PM, Mr Dash Four wrote:>>> Instead of manually adding "SAVE I:N", "SAVE O:N" and then "RESTORE >>> I:ER", "RESTORE O:ER" etc. at the end of each chain (as this would be >>> the most efficient way of dealing with SELinux contexts once they are >>> established) it would be nice if these things are ''optimised'' and added >>> automatically by Shorewall when an appropriate option is turned on in >>> shorewall.conf (like "AUTO_CONNSECMARK=Yes" for example) so that I do >>> not have to put these manually. >>> >>> As I already pointed out - in vast majority of cases SAVE and RESTORE >>> would make sense to be placed in the above form at the end of each chain >>> so that they take care of preserving and restoring SELinux contexts in >>> connections, so why not add them automatically?>> > Flexibility indeed! Hence why I suggested that you could add an option > (or include it as another optimisation level as you currently do with so > many other things on Shorewall) and let Shorewall users decide what to use. > > Another reason for this is that mistakes with SAVE and RESTORE are > *very* easy to make as I found out to my own cost (using SAVE > "I:N"/"RESTORE I:ER" with attaching additional parameters - ports etc - > which is an absolute rubbish thing to do!) - hence if I know that my > network deploys SELinux (which is what I aim for really) and all network > traffic is controlled I just switch this option on, Shorewall attaches > SAVE/RESTORE statements at the end of each CHAIN ''automatically'' and the > only thing I need to concentrate on, as far as secmarks are concerned, > is defining the SELinux contexts for the traffic I am controlling. > > For others, who do not need/do not want to use this approach and prefer > to do everything ''manually'' they can switch this option off and get on > with it without additional hassle. Very much like the optimisation > levels you have currently built in Shorewall. > > You don''t take anything away, on the contrary - you provide flexibility > and keep everyone happy!I wonder if a better way to approach this might be with "secmark macros"; canned blocks of rules that can be invoked easily. We really should take this discussion onto the Development Mailing List. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
On 9/7/10 3:27 PM, Mr Dash Four wrote:> Tom Eastep wrote: > >> I will consider a shorewall.conf (shorewall6.conf) option as a follow-on >> enhancement, but given how much more popular tcrules are than secmarks, >> I would probably add the enhancement for tcrules first. >> > No worries, just expressing my opinion - the decision, ultimately, is > for you to make, that''s all.Before I implement such a thing, I need to be sure that I understand all of the ramifications. I''m nowhere near that level of understanding with respect to SECMARK/CONNSECMARK. So I would prefer to implement very basic tools and then let user experience help drive where we go from there. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
> That must not have been the second RPM I sent -- I just installed the > second one (taken from my mailer''s ''sent'' log) on a SuSE box and tested > with the following nonsense secmarks file: > > COMMENT foo > a:b:c I:N lo 127.0.0.1 tcp 3306 > COMMENT >It does work now - I must have been doing it the wrong way.> I would appreciate getting a copy of your finished secmarks > configuration so I can include it as an example on the web site and in > the document packages. >Will do when I am finished - I am not ready yet though (had a very busy week). ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev
>>>> Instead of manually adding "SAVE I:N", "SAVE O:N" and then "RESTORE >>>> I:ER", "RESTORE O:ER" etc. at the end of each chain (as this would be >>>> the most efficient way of dealing with SELinux contexts once they are >>>> established) it would be nice if these things are ''optimised'' and added >>>> automatically by Shorewall when an appropriate option is turned on in >>>> shorewall.conf (like "AUTO_CONNSECMARK=Yes" for example) so that I do >>>> not have to put these manually. >>>> >>>> As I already pointed out - in vast majority of cases SAVE and RESTORE >>>> would make sense to be placed in the above form at the end of each chain >>>> so that they take care of preserving and restoring SELinux contexts in >>>> connections, so why not add them automatically? >>>> >> Flexibility indeed! Hence why I suggested that you could add an option >> (or include it as another optimisation level as you currently do with so >> many other things on Shorewall) and let Shorewall users decide what to use. >> >> Another reason for this is that mistakes with SAVE and RESTORE are >> *very* easy to make as I found out to my own cost (using SAVE >> "I:N"/"RESTORE I:ER" with attaching additional parameters - ports etc - >> which is an absolute rubbish thing to do!) - hence if I know that my >> network deploys SELinux (which is what I aim for really) and all network >> traffic is controlled I just switch this option on, Shorewall attaches >> SAVE/RESTORE statements at the end of each CHAIN ''automatically'' and the >> only thing I need to concentrate on, as far as secmarks are concerned, >> is defining the SELinux contexts for the traffic I am controlling. >> >> For others, who do not need/do not want to use this approach and prefer >> to do everything ''manually'' they can switch this option off and get on >> with it without additional hassle. Very much like the optimisation >> levels you have currently built in Shorewall. >> >> You don''t take anything away, on the contrary - you provide flexibility >> and keep everyone happy! >> > > I wonder if a better way to approach this might be with "secmark > macros"; canned blocks of rules that can be invoked easily. >If by that you mean macros like ''Ping'', ''Drop'' etc I don''t see much benefit in doing that. My understanding of how SAVE/RESTORE works is that it makes sense to include SAVE at the end of each chain when STATE=NEW (statement like ''SAVE X:N'') - at the very end where all SECMARK rules are specified; and use RESTORE also at the end of each chain when STATE=ESTABLISHED, RELATED (statement like ''RESTORE X:ER'') for the SELinux context to be restored to its (previously) saved state on already established connections. With macros, as far as I know, you can include them anywhere, so it defeats the whole purpose - I may as well put the actual statement (which isn''t very long as you can see from above) instead of using a macro. The benefit of ''automatically'' (for want of better word) including SAVE/RESTORE in the way I listed above is to ''automatically'' save and restore the SELinux context state and allow people like my to concentrate on writing down the actual SECMARK rules. Again, with an option (may be in the shorewall.conf) this behaviour could be switched on/off as desired so that nobody feels excluded or ''boxed-in''.> We really should take this discussion onto the Development Mailing List. >Just did and slightly altered the title of the thread - feel free to move/alter this as desired! As an aside question - when I list my active connections (with ''shorewall show connections'') I get the secmark field, but it is numerical (something like ''secmark=xxx''). Is it possible to somehow convert this numerical value to the actual security context I specified so that I can trace which is which? ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev
>> No worries, just expressing my opinion - the decision, ultimately, is >> for you to make, that''s all. >> > > Before I implement such a thing, I need to be sure that I understand all > of the ramifications. I''m nowhere near that level of understanding with > respect to SECMARK/CONNSECMARK. > > So I would prefer to implement very basic tools and then let user > experience help drive where we go from there. >Sure, it is a learning process for me as well, but by using this every day I am getting a better understanding of how it works. I may be able to prepare more detailed analysis when I get the complete picture (particularly on the Shorewall side of things) - I am still not there yet though. ------------------------------------------------------------------------------ Automate Storage Tiering Simply Optimize IT performance and efficiency through flexible, powerful, automated storage tiering capabilities. View this brief to learn how you can reduce costs and improve performance. http://p.sf.net/sfu/dell-sfdev2dev
On 9/10/10 4:08 AM, Mr Dash Four wrote:> >>>>> Instead of manually adding "SAVE I:N", "SAVE O:N" and then "RESTORE >>>>> I:ER", "RESTORE O:ER" etc. at the end of each chain (as this would be >>>>> the most efficient way of dealing with SELinux contexts once they are >>>>> established) it would be nice if these things are ''optimised'' and added >>>>> automatically by Shorewall when an appropriate option is turned on in >>>>> shorewall.conf (like "AUTO_CONNSECMARK=Yes" for example) so that I do >>>>> not have to put these manually. >>>>> >>>>> As I already pointed out - in vast majority of cases SAVE and RESTORE >>>>> would make sense to be placed in the above form at the end of each chain >>>>> so that they take care of preserving and restoring SELinux contexts in >>>>> connections, so why not add them automatically? >>>>> >>> Flexibility indeed! Hence why I suggested that you could add an option >>> (or include it as another optimisation level as you currently do with so >>> many other things on Shorewall) and let Shorewall users decide what to use. >>> >>> Another reason for this is that mistakes with SAVE and RESTORE are >>> *very* easy to make as I found out to my own cost (using SAVE >>> "I:N"/"RESTORE I:ER" with attaching additional parameters - ports etc - >>> which is an absolute rubbish thing to do!) - hence if I know that my >>> network deploys SELinux (which is what I aim for really) and all network >>> traffic is controlled I just switch this option on, Shorewall attaches >>> SAVE/RESTORE statements at the end of each CHAIN ''automatically'' and the >>> only thing I need to concentrate on, as far as secmarks are concerned, >>> is defining the SELinux contexts for the traffic I am controlling. >>> >>> For others, who do not need/do not want to use this approach and prefer >>> to do everything ''manually'' they can switch this option off and get on >>> with it without additional hassle. Very much like the optimisation >>> levels you have currently built in Shorewall. >>> >>> You don''t take anything away, on the contrary - you provide flexibility >>> and keep everyone happy! >>> >> >> I wonder if a better way to approach this might be with "secmark >> macros"; canned blocks of rules that can be invoked easily. >> > If by that you mean macros like ''Ping'', ''Drop'' etc I don''t see much > benefit in doing that. > > My understanding of how SAVE/RESTORE works is that it makes sense to > include SAVE at the end of each chain when STATE=NEW (statement like > ''SAVE X:N'') - at the very end where all SECMARK rules are specified; and > use RESTORE also at the end of each chain when STATE=ESTABLISHED, > RELATED (statement like ''RESTORE X:ER'') for the SELinux context to be > restored to its (previously) saved state on already established > connections. With macros, as far as I know, you can include them > anywhere, so it defeats the whole purpose - I may as well put the actual > statement (which isn''t very long as you can see from above) instead of > using a macro.My point is that the save/restore rules are 2 LINES per chain, no matter how simple or complex the other entries are; a reasonably-written HOWTO can explain where to put them such that even the dimmest admin can get that part right. I''m talking about the rules for the various applications themselves. Something akin to the scripts found at http://people.redhat.com/jmorris/selinux/secmark/.> > As an aside question - when I list my active connections (with > ''shorewall show connections'') I get the secmark field, but it is > numerical (something like ''secmark=xxx''). Is it possible to somehow > convert this numerical value to the actual security context I specified > so that I can trace which is which?That display is not produced by Shorewall; you can get exactly the same thing using the command ''cat /proc/net/ip_conntrack''. There may be something in /proc that allows the requested translation; patches cheerfully accepted. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev