bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start"

[Eugene Grosbein]

On -9.01.-28163 02:59, Ian Smith wrote:
> On Sat, 18 Dec 2010, Alexander Verbod wrote:
>  >  Eugene Grosbein <eugen at grosbein.pp.ru> wrote:
>  >  
>  >  > One should not unconditionally disable ability of reloading ipfw rules
>  >  > using "/etc/rc.d/ipfw start" command.
>  >  
>  >  Patch  doesn't "unconditionally disable ability of reloading ipfw rules"!

"unconditionally disable ability of reloading ipfw rules using
'/etc/rc.d/ipfw start' command" - will this way of reloading ipfw rules
work with your patch applied? It seems, no.

>  >  Patch disables the ability to run start up script "/etc/rc.d/ipfw"
>  >  with "start" command twice that causes lockdown even if type of firewall
>  >  is "OPEN".

It does not cause lockdown if used in right way, I do this all the time.

>  >  By the term "reloading" I guess you meant the "restart" command
>  >  that's doing stop/start sequence, but not start/start. ;)

Disabling firewall is not an option.
There must be a way to reload rules without passing packets by meantime.
This way now is "/etc/rc.d/ipfw start" command.

>  >  > For example, it's used extensively
>  >  > in my systems and does not lead to "lock-down".
>  >  
>  >  Eugene, you could do with your systems whatever you want, but here was 
>  >  described the bug that appears when used standard, non modified OS.

Of course, with standard OS.

>  >  Did you try all steps described in the "How-To-Repeat" section before replying?

Yes. No problems here.

>  >  > One should learn ipfw(8) manual page including CHECKLIST paragraph
>  >  
>  >  :) 
>  >  
>  >  Could you check please /etc/rc.firewall for presence of this line
>  >  "${fwcmd} add 65000 pass all from any to any"
>  >  It's the only one line for "OPEN" firewall's profile.

Yes.

>  >  One who claim to know ipfw(8) manual page should understand this
>  >  firewall's rule that unconditionally allow all traffic in both direction for any
>  >  type of protocols. But after running "/etc/rc.d/ipfw start" twice all rules are
>  >  flashed and only default rule: 
>  >  65535 deny ip from any to any
>  >  to take affect.

Yes, that's intentional. Then 'allow' rule is loaded again,
if you use the command right way.

> Yes, because you're running /etc/rc.d/ipfw start over the network, which 
> I think disabling the firewall in ipfw_prestart() should fix.  Comments?

I don't think we should disable firewall (creating 'open' window).

>  >  > and make oneself familiar with proper ways of reloading ipfw over
>  >  > network.
>  >  
>  >  Did I say somewhere that I don't know "proper ways of reloading ipfw
>  >  over network"?

Proper way is the way when your system does not lock down.

>  >  > 2. Nice catch. 
>  >  It isn't a catch, it's a report about bugs.
> 
> Try not taking critique too defensively.  Perhaps a language problem; 
> 'nice catch' is a compliment; you caught a bug, it should be ${SYSCTL_W}

Exactly, thanks for clarification.

> There's another part of your patch that Eugene didn't comment on that 
> caught my eye:
> 
> -firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +
> +if checkyesno firewall_nat_enable; then
> +        firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +elif checkyesno natd_enable; then
> +        firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
> +fi
> 
> Firstly, there's no problem with running /etc/rc.d/natd in any case, as 
> it won't do anything (ie is a NOP) unless natd_enable is set in rc.conf.
> 
> Secondly, having firewall_nat_enable set has no need or use for loading 
> natd, they're quite separate methods of performing NAT.

Nice catch ;-) I've overlooked this.

Eugene Grosbein