From nobody@FreeBSD.org  Fri Dec 17 16:21:40 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 28C0C106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Dec 2010 16:21:40 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (unknown [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 165EA8FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Dec 2010 16:21:40 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id oBHGLdR5040974
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 17 Dec 2010 16:21:39 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id oBHGLdsP040973;
	Fri, 17 Dec 2010 16:21:39 GMT
	(envelope-from nobody)
Message-Id: <201012171621.oBHGLdsP040973@red.freebsd.org>
Date: Fri, 17 Dec 2010 16:21:39 GMT
From: Alexander Verbod <AlexJ@freebsd.forum>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start"
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         153252
>Category:       bin
>Synopsis:       [ipfw][patch] ipfw lockdown system in subsequent call of "/etc/rc.d/ipfw start"
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ipfw
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Dec 17 16:30:14 UTC 2010
>Closed-Date:    
>Last-Modified:  Wed Dec 22 17:10:10 UTC 2010
>Originator:     Alexander Verbod
>Release:        8.1-RELEASE
>Organization:
>Environment:
FreeBSD test.private.local 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
1. Firewall lock-down system if script "/etc/rc.d/ipfw start" called twice.

2. "sysctl" utility inside "/etc/rc.d/ipfw" script used without full path
   prefix that cause error in case if PATH environment variable contain path
   to current directory "./" and script called from directory "/etc/rc.d"

3. /etc/rc.d/ipfw script always add "/etc/rc.d/natd" to "firewall_coscripts"
   variable regardless if "natd" was enabled in rc.conf or not.

>How-To-Repeat:
Add to "/etc/rc.conf" following strings:

#=====================
firewall_enable='YES'
firewall_type='OPEN'
firewall_logging='YES'
firewall_quiet='NO'

firewall_nat_enable='NO'
natd_enable='NO'
dummynet_enable='NO'
#=====================

then start firewall:
/etc/rc.d/ipfw start

second attempt to run 
/etc/rc.d/ipfw start

will lock-down system

>Fix:
Attached patch will fix all three issues

Patch attached with submission follows:

*** ipfw.orig	2010-07-31 18:52:54.000000000 -0400
--- ipfw	2010-12-17 10:02:54.000000000 -0500
***************
*** 39,45 ****
--- 39,56 ----
  
  	_firewall_type=$1
  
+ 	# check if firewall already running to prevent subsequent start calls
+ 	#
+ 	[ $( ${SYSCTL_N} net.inet.ip.fw.enable ) -ne 0 ] && {
+ 		warn 'Firewall is already running.';
+ 		_ipfw_running_status=1;
+ 		return 1;
+ 	} || {
+ 		_ipfw_running_status=0;
+ 	}
+ 
  	# set the firewall rules script if none was specified
+ 	#
  	[ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall
  
  	if [ -r "${firewall_script}" ]; then
***************
*** 55,61 ****
  	#
  	if checkyesno firewall_logging; then
  		echo 'Firewall logging enabled.'
! 		sysctl net.inet.ip.fw.verbose=1 >/dev/null
  	fi
  }
  
--- 66,72 ----
  	#
  	if checkyesno firewall_logging; then
  		echo 'Firewall logging enabled.'
! 		${SYSCTL_W} net.inet.ip.fw.verbose=1 >/dev/null
  	fi
  }
  
***************
*** 63,72 ****
  {
  	local	_coscript
  
  	# Start firewall coscripts
  	#
  	for _coscript in ${firewall_coscripts} ; do
! 		if [ -f "${_coscript}" ]; then
  			${_coscript} quietstart
  		fi
  	done
--- 74,89 ----
  {
  	local	_coscript
  
+ 	# stop proccessing if firewall is already running
+ 	#
+ 	[ ${_ipfw_running_status} -eq 1 ] && {
+ 		return 1;
+ 	}
+ 
  	# Start firewall coscripts
  	#
  	for _coscript in ${firewall_coscripts} ; do
! 		if [ -f "${_coscript}" -a -x "${_coscript}" ]; then
  			${_coscript} quietstart
  		fi
  	done
***************
*** 98,110 ****
  	# Stop firewall coscripts
  	#
  	for _coscript in `reverse_list ${firewall_coscripts}` ; do
! 		if [ -f "${_coscript}" ]; then
  			${_coscript} quietstop
  		fi
  	done
  }
  
  load_rc_config $name
! firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
  
  run_rc_command $*
--- 115,132 ----
  	# Stop firewall coscripts
  	#
  	for _coscript in `reverse_list ${firewall_coscripts}` ; do
! 		if [ -f "${_coscript}" -a -x "${_coscript}" ]; then
  			${_coscript} quietstop
  		fi
  	done
  }
  
  load_rc_config $name
! 
! 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
  
  run_rc_command $*


>Release-Note:
>Audit-Trail:

From: Eugene Grosbein <eugen@grosbein.pp.ru>
To: bug-followup@freebsd.org
Cc: AlexJ@freebsd.forum
Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent
 call of "/etc/rc.d/ipfw start"
Date: Sat, 18 Dec 2010 02:38:45 +0600

 1.
 
 > # check if firewall already running to prevent subsequent start calls
 
 One should not unconditionally disable ability of reloading ipfw rules
 using "/etc/rc.d/ipfw start" command. For example, it's used extensively
 in my systems and does not lead to "lock-down". One should learn
 ipfw(8) manual page including CHECKLIST paragraph and make oneself
 familiar with proper ways of reloading ipfw over network.
 
 2. Nice catch. However, that's only one of reasons why it is
 very bad habit to have "./" in PATH.
 
 3. Please use "diff -u" to make unified diffs,
 they are much easier to read.
 
 Eugene Grosbein
Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Dec 17 22:11:53 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=153252 

From: "Alexander Verbod" <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call
 of "/etc/rc.d/ipfw start"
Date: Sat, 18 Dec 2010 15:00:01 -0500

 --========GMX20051292702401607924
 Content-Type: text/plain; charset="utf-8"
 Content-Transfer-Encoding: 8bit
 
 Eugene Grosbein <eugen@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"!
 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".
 
 By the term "reloading" I guess you meant the "restart" command
 that's doing stop/start sequence, but not start/start. ;)
 
 > 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.
 
 Did you try all steps described in the "How-To-Repeat" section before replying?
 
 
 > 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.
 
 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.
 
 
 > 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"?
 If one like to show of, bug report board isn't a good place to do that.
 
 > 2. Nice catch. 
 It isn't a catch, it's a report about bugs.
 
 > However, that's only one of reasons why it is
 > very bad habit to have "./" in PATH.
 
 It is a perfectly legal operation that shouldn't cause an error on the OS level.
 If one can't use a hummer and broke his finger because of that - it isn't mean
 that hummer is a bad tool.
 
 > 3. Please use "diff -u" to make unified diffs,
 > they are much easier to read.
 
 I'm agree with you on that but I used official advice
 http://www.freebsd.org/doc/en/articles/contributing/contrib-how.html
 that says:
 "The preferred diff(1) format for submitting patches is the unified 
 output format generated by diff -u. 
 However, for patches that substantially change a region of code, 
 a context output format diff generated by diff -c may be more readable
 and thus preferable."
 
 Unified patch attached.
 
 --========GMX20051292702401607924
 Content-Type: application/octet-stream; charset="utf-8"; name="ipfw.patch2.txt"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="ipfw.patch2.txt"
 Content-Description: Attachment: ipfw.patch2.txt
 
 LS0tIGlwZncub3JpZwkyMDEwLTA3LTMxIDE4OjUyOjU0LjAwMDAwMDAwMCAtMDQwMAorKysgaXBm
 dwkyMDEwLTEyLTE3IDEwOjAyOjU0LjAwMDAwMDAwMCAtMDUwMApAQCAtMzksNyArMzksMTggQEAK
 IAogCV9maXJld2FsbF90eXBlPSQxCiAKKwkjIGNoZWNrIGlmIGZpcmV3YWxsIGFscmVhZHkgcnVu
 bmluZyB0byBwcmV2ZW50IHN1YnNlcXVlbnQgc3RhcnQgY2FsbHMKKwkjCisJWyAkKCAke1NZU0NU
 TF9OfSBuZXQuaW5ldC5pcC5mdy5lbmFibGUgKSAtbmUgMCBdICYmIHsKKwkJd2FybiAnRmlyZXdh
 bGwgaXMgYWxyZWFkeSBydW5uaW5nLic7CisJCV9pcGZ3X3J1bm5pbmdfc3RhdHVzPTE7CisJCXJl
 dHVybiAxOworCX0gfHwgeworCQlfaXBmd19ydW5uaW5nX3N0YXR1cz0wOworCX0KKwogCSMgc2V0
 IHRoZSBmaXJld2FsbCBydWxlcyBzY3JpcHQgaWYgbm9uZSB3YXMgc3BlY2lmaWVkCisJIwogCVsg
 LXogIiR7ZmlyZXdhbGxfc2NyaXB0fSIgXSAmJiBmaXJld2FsbF9zY3JpcHQ9L2V0Yy9yYy5maXJl
 d2FsbAogCiAJaWYgWyAtciAiJHtmaXJld2FsbF9zY3JpcHR9IiBdOyB0aGVuCkBAIC01NSw3ICs2
 Niw3IEBACiAJIwogCWlmIGNoZWNreWVzbm8gZmlyZXdhbGxfbG9nZ2luZzsgdGhlbgogCQllY2hv
 ICdGaXJld2FsbCBsb2dnaW5nIGVuYWJsZWQuJwotCQlzeXNjdGwgbmV0LmluZXQuaXAuZncudmVy
 Ym9zZT0xID4vZGV2L251bGwKKwkJJHtTWVNDVExfV30gbmV0LmluZXQuaXAuZncudmVyYm9zZT0x
 ID4vZGV2L251bGwKIAlmaQogfQogCkBAIC02MywxMCArNzQsMTYgQEAKIHsKIAlsb2NhbAlfY29z
 Y3JpcHQKIAorCSMgc3RvcCBwcm9jY2Vzc2luZyBpZiBmaXJld2FsbCBpcyBhbHJlYWR5IHJ1bm5p
 bmcKKwkjCisJWyAke19pcGZ3X3J1bm5pbmdfc3RhdHVzfSAtZXEgMSBdICYmIHsKKwkJcmV0dXJu
 IDE7CisJfQorCiAJIyBTdGFydCBmaXJld2FsbCBjb3NjcmlwdHMKIAkjCiAJZm9yIF9jb3Njcmlw
 dCBpbiAke2ZpcmV3YWxsX2Nvc2NyaXB0c30gOyBkbwotCQlpZiBbIC1mICIke19jb3NjcmlwdH0i
 IF07IHRoZW4KKwkJaWYgWyAtZiAiJHtfY29zY3JpcHR9IiAtYSAteCAiJHtfY29zY3JpcHR9IiBd
 OyB0aGVuCiAJCQkke19jb3NjcmlwdH0gcXVpZXRzdGFydAogCQlmaQogCWRvbmUKQEAgLTk4LDEz
 ICsxMTUsMTggQEAKIAkjIFN0b3AgZmlyZXdhbGwgY29zY3JpcHRzCiAJIwogCWZvciBfY29zY3Jp
 cHQgaW4gYHJldmVyc2VfbGlzdCAke2ZpcmV3YWxsX2Nvc2NyaXB0c31gIDsgZG8KLQkJaWYgWyAt
 ZiAiJHtfY29zY3JpcHR9IiBdOyB0aGVuCisJCWlmIFsgLWYgIiR7X2Nvc2NyaXB0fSIgLWEgLXgg
 IiR7X2Nvc2NyaXB0fSIgXTsgdGhlbgogCQkJJHtfY29zY3JpcHR9IHF1aWV0c3RvcAogCQlmaQog
 CWRvbmUKIH0KIAogbG9hZF9yY19jb25maWcgJG5hbWUKLWZpcmV3YWxsX2Nvc2NyaXB0cz0iL2V0
 Yy9yYy5kL25hdGQgJHtmaXJld2FsbF9jb3NjcmlwdHN9IgorCitpZiBjaGVja3llc25vIGZpcmV3
 YWxsX25hdF9lbmFibGU7IHRoZW4KKwlmaXJld2FsbF9jb3NjcmlwdHM9Ii9ldGMvcmMuZC9uYXRk
 ICR7ZmlyZXdhbGxfY29zY3JpcHRzfSIKK2VsaWYgY2hlY2t5ZXNubyBuYXRkX2VuYWJsZTsgdGhl
 bgorCWZpcmV3YWxsX2Nvc2NyaXB0cz0iL2V0Yy9yYy5kL25hdGQgJHtmaXJld2FsbF9jb3Njcmlw
 dHN9IgorZmkKIAogcnVuX3JjX2NvbW1hbmQgJCoK
 --========GMX20051292702401607924--

From: Eugene Grosbein <egrosbein@rdtc.ru>
To: Ian Smith <smithi@nimnet.asn.au>
Cc: Alexander Verbod <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com>,
        freebsd-ipfw@freebsd.org, Alexander Verbod <AlexJ@freebsd.forum>,
        bug-followup@freebsd.org
Subject: Re: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent
 call of "/etc/rc.d/ipfw start"
Date: Sun, 19 Dec 2010 20:25:52 +0600

 On -9.01.-28163 02:59, Ian Smith wrote:
 > On Sat, 18 Dec 2010, Alexander Verbod wrote:
 >  >  Eugene Grosbein <eugen@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

From: Chris St Denis <chris@smartt.com>
To: bug-followup@FreeBSD.org, AlexJ@freebsd.forum
Cc:  
Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent
 call of "/etc/rc.d/ipfw start"
Date: Mon, 20 Dec 2010 09:45:04 -0800

 If I understand this problem correctly, the lockdown is caused by the 
 ssh session getting killed off between the "${fwcmd} -f flush" and the 
 subsequent add rules in rc.firewall (or other user-defined custom script).
 
 If this is the case, couldn't the issue be resolved with a simple patch 
 along the lines of this?
 
 --- ipfw.old    2010-12-20 09:41:02.000000000 -0800
 +++ ipfw        2010-12-20 09:42:02.000000000 -0800
 @@ -43,7 +43,7 @@
          [ -z "${firewall_script}" ] && firewall_script=/etc/rc.firewall
 
          if [ -r "${firewall_script}" ]; then
 -               /bin/sh "${firewall_script}" "${_firewall_type}"
 +               /usr/bin/nohup /bin/sh "${firewall_script}" 
 "${_firewall_type}"
                  echo 'Firewall rules loaded.'
          elif [ "`ipfw list 65535`" = "65535 deny ip from any to any" ]; 
 then
                  echo 'Warning: kernel has firewall functionality, but' \
 
 
 -- 
 Chris St Denis
 Programmer
 SmarttNet (www.smartt.com)
 Ph: 604-473-9700 Ext. 200
 -------------------------------------------
 "Smart Internet Solutions For Businesses"
 

From: "Alexander Verbod" <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com>
To: bug-followup@FreeBSD.org
Cc: freebsd-ipfw@freebsd.org,"Ian Smith" <smithi@nimnet.asn.au>,"Eugene
 Grosbein" <egrosbein@rdtc.ru>
Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call
 of "/etc/rc.d/ipfw start"
Date: Wed, 22 Dec 2010 10:03:26 -0500

 Ian Smith <smithi@nimnet.asn.au> wrote:
 
 > Please treat this as a general discussion of issues, as well as your PR.
 > Try not taking critique too defensively.  Perhaps a language problem;
 
 I'd always like to learn from people, but if someone can't see
 difference between /sbin/ipfw and /etc/rc.d/ipfw and point wrongly to manual
 page of /sbin/ipfw(8) while talking many times about some special secret
 'right way' how to run _START UP_ script - I just simply trying to explain
 that is wrong in my opinion, so no any defense or aggression :)
 
 Ian Smith <smithi@nimnet.asn.au> wrote:
 > There may be a easier solution to this problem than having start fail if 
 > the firewall is already enabled .. that is, simply disable the firewall 
 > in ipfw_prestart(); it's enabled again in ipfw_poststart() and as you 
 > see there, it'd be necessary to test for and disable both IPv4 and IPv6 
 > firewalls anyway.
 
 I don't think that using ipfw_prestart()/ipfw_poststart() mechanism is 
 a good way to resolve this issue. As Eugene already point it out - it will 
 disable firewall for a while that will create window when there will be no 
 firewall protection at all.
 
 The simplest way to satisfy everybody is to add on the 
 top of "/etc/rc.d/ipfw" and "/etc/rc.firewall" this string:
 trap ':' 1 2 5 15;
 It will guaranty that script doesn't stop in a middle when 
 ${fwcmd} -f flush
 command will be executed that broke connection anyway but at least 
 it will allow to finish apply firewall rules and then will be possible to
 relogin again, but I don't think it is a nice solution.
 
 IMHO reloading firewall's rules should be handled by additional command such
 as "reload" or similar but not in the "start" action because "start" must mean 
 "start" only.
 Does anybody can start running again for example without prior stopping?
 Start must be start. Official documentation doesn't provide any 
 explanation how to handle in a special way some particular _start up_ scripts.
 Right way to applying firewall's rules over network explained very well for
 /sbin/ipfw but not for /etc/rc.d/ipfw and I believe it is right.
 
 I think it should be kept simple - start up script load initial firewall's
 rule and after that one should handle reloading of firewall's rules with
 own scripts by calling /sbin/ipfw that is intended exactly to do this kind
 of actions.
 
 Running command "start" twice is meaningless. If one want to reload 
 firewall's rules with 
 /etc/rc.d/ipfw then there should be implemented safe command "reload"
 or something else, but I don't think it is a good idea.
 /etc/rc.d/ipfw is a mechanism that generally 
 control service - enable it or not.
 If one need just reload firewall's rules it could be done by running
 /etc/rc.firewall script enclosed in guarding script instead of 
 "/etc/rc.d/ipfw start", something like this:
 
 /bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;"
 
 or simply
 
 /usr/bin/nohup /bin/sh /etc/rc.firewall
 
 in case if /usr already mounted.
 
 Ian Smith <smithi@nimnet.asn.au> wrote:
 > One of the reasons that people might want to run 'start' again when it's 
 > already running is described in (at least) both of:
 I'm sorry, but running twice '/etc/rc.d/ipfw start' isn't solution in that case.
 I think the right solution is to fix logical bug and run natd first before 
 loading firewall rules instead of running "start" command twice.
 (BTW, it's impossible to run '/etc/rc.d/ipfw start' on boot twice,
  so it could be a solution)
 
 
 Ian Smith <smithi@nimnet.asn.au> wrote:
 > 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?
 Well, actually it wasn't me who "running '/etc/rc.d/ipfw start' over 
 the network", it was my students who learning to manage FreeBSD. They 
 wrote some script that accidentally called twice "/etc/rc.d/ipfw start" and
 I explained them that they couldn't be born twice, so the ipfw service 
 couldn't be logically started twice too. 
 
 
 Add code below to /etc/rc.d/ipfw
 
 #--------------
 extra_commands='reload'
 reload_cmd='ipfw_reload'
 
 ipfw_reload() {
  /bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;"
 }
 #--------------
 
 add 
 
 #--------------
 trap ':' 1 2
 #--------------
 
 on top of /etc/rc.d/ipfw and /etc/rc.firewall
 
 and you'll have safe way to reload firewall's rules if you want.
 
 Disabling the firewall in ipfw_prestart() IMHO isn't right.
 
 
 Ian Smith <smithi@nimnet.asn.au> wrote:
 > Nonetheless, Eugene's advice is worthwhile, ./ in PATH is never a good 
 > idea when discussing security, which is what a firewall is all about.
 Well, I completely agree with you and Eugene on that if it come to a 
 general security. This is kind of topic, but you forget that some 
 projects don't need to be opened to the wild internet, it could be an 
 automatic stations in closed environment where using ./ in the PATH can 
 simplify things a lot without any security issues.
 The point is that OS should protected itself from tricks that could be 
 done with ./ in the PATH. Providing full path to the programs on an 
 OS level is always a good idea.
 
 Ian Smith <smithi@nimnet.asn.au> wrote:
 > 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.
 
 If it won't to do anything then why OS need to execute additional useless
 operations? 
 /etc/rc.d/ipfw is already checked in ipfw_prestart() function
 - is nat needed or not, so no any reason to complicate it.
 I prefer in source code clear logic - if it isn't needed then it 
 shouldn't be run and this logic IMHO should be handled in one 
 place to guaranty simplicity and independence. It just a couple of 
 strings that wouldn't bloat OS but increase speed of boot process by
 excluding useless operations.
 
 Anyway all this code block could be excluded if nat will be loaded 
 in ipfw_prestart() function that will fix issue shown in PR's:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=153155
 http://www.freebsd.org/cgi/query-pr.cgi?pr=148137
 
 and exclude useless operation such as 
 firewall_coscripts="/etc/rc.d/natd ${firewall_coscripts}"
 in the end of /etc/rc.d/ipfw
 
 
 
 
 Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 > "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.
 Eugene, don't take my words as offense please, lets talk about technical
 aspects only.
 Do you reload MySql with '/usr/local/etc/rc.d/mysql-server start'?
 I guess - no. The same with other services because meaning of word "start"
 is to born new instance of something.
 "/etc/rc.d/ipfw start" isn't exclusion, it should follow human's logic.
 If one want to reload firewall's rules he/she need to implement command "reload".
 
 Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 > It does not cause lockdown if used in right way, I do this all the time.
 Instead of repeating many times about magic "right way" could you point me
 to documentation where is this "right way" explained?
 Don't point me to ipfw(8) manual page again please because it describe 
 "/sbin/ipfw" but isn't "/etc/rc.d/ipfw".
 There is a big difference between them.
 
 I didn't saw in the documentation a special 'right way' of using rc.d start up
 scripts. May be I miss something, may be you.
 You can execute anyone scripts without any parameters in rc.d directory and it 
 will show all available arguments that can be passed to scripts.
 I didn't found anyone rc scripts that says it need to be used in a special
 "right way".
 There no and shouldn't be any special tricks to run start up scripts.
 
 
 
 Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 > 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.
 Absolutely agree with you on that - "Disabling firewall is not an option" 
 but reloading firewall's rules by employ "/etc/rc.d/ipfw start" isn't
 an option too. I guess all our disagreement is because there no command 
 "reload" for ipfw service.
 
 
 Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 >  >  Did you try all steps described in the "How-To-Repeat" section before replying?
 > Yes. No problems here.
 I bet you did it from system console or by enclosing "/etc/rc.d/ipfw start"
 to surrounding guarding script, otherwise if you don't protect 
 '/etc/rc.d/ipfw start' from interruption then first 
 "ipfw -f flash" command will broke connection to the box and script
 "/etc/rc.d/ipfw" will stop execution in a middle by leaving box inaccessible
 over network.
 
 
 Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 > Ian Smith <smithi@nimnet.asn.au> wrote:
 > > 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.
 
 I don't agree with you guys here. 
 There no any reason to execute /etc/rc.d/natd if it will not be used.
 Pointless operation. 
 You create multiple dependency that is hard to track it down. 
 Each script should be independent as much as possible and don't relay
 on assumption that /etc/rc.d/natd wouldn't start never.
 Why not to handle all logic in one place instead of creating 
 possible holes. It just three additional lines that whouldn't bloat OS to the
 hell but ensure clear logic of operations and exclude useless running
 of /etc/rc.d/natd if it disabled. 
 There already exist condition statements in the ipfw_prestart()
 function that tried to figure out if nat will be used or not, so IMHO
 better to handle it exactly in that place where test condition was done instead of
 cheese it up across multiple scripts.

From: "Alexander Verbod" <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com>
To: bug-followup@FreeBSD.org
Cc: freebsd-ipfw@freebsd.org,"Chris St Denis" <chris@smartt.com>
Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent call
 of "/etc/rc.d/ipfw start"
Date: Wed, 22 Dec 2010 10:08:01 -0500

 Chris St Denis <chris@smartt.com> wrote:
 > If I understand this problem correctly, the lockdown is caused by the
 > ssh session getting killed off between the "${fwcmd} -f flush" and the
 > subsequent add rules in rc.firewall (or other user-defined custom script).
 
 You right, "${fwcmd} -f flush" will broke connection to remote machine and start
 up script stop its execution, so no any firewall's rules applied and only 
 default 65536 deny rule is in charge.
 
 >
 > If this is the case, couldn't the issue be resolved with a simple patch
 > along the lines of this?
 >
 > + /usr/bin/nohup /bin/sh "${firewall_script}"
 
 /usr couldn't be available on start up time, so IMHO it will be better
 to use /bin/sh -T .... as I already show it in the previous post.
 

From: Eugene Grosbein <egrosbein@rdtc.ru>
To: Alexander Verbod <UMLLMTHW8EWBC7QMJE.3FZA88RFFWF@gmx.com>
Cc: bug-followup@freebsd.org, freebsd-ipfw@freebsd.org,
        Ian Smith <smithi@nimnet.asn.au>
Subject: Re: bin/153252: [ipfw][patch] ipfw lockdown system in subsequent
 call of "/etc/rc.d/ipfw start"
Date: Wed, 22 Dec 2010 23:07:18 +0600

 On 22.12.2010 21:03, Alexander Verbod wrote:
 > Ian Smith <smithi@nimnet.asn.au> wrote:
 > 
 >> Please treat this as a general discussion of issues, as well as your PR.
 >> Try not taking critique too defensively.  Perhaps a language problem;
 > 
 > I'd always like to learn from people, but if someone can't see
 > difference between /sbin/ipfw and /etc/rc.d/ipfw and point wrongly to manual
 > page of /sbin/ipfw(8) while talking many times about some special secret
 > 'right way' how to run _START UP_ script - I just simply trying to explain
 > that is wrong in my opinion, so no any defense or aggression :)
 
 No secrets here. You was pointed to section that has second paragraph
 leading to /usr/share/examples/ipfw/change_rules.sh.
 
 Examples directory, right? This script shows proper way.
 
 > IMHO reloading firewall's rules should be handled by additional command such
 > as "reload" or similar but not in the "start" action because "start" must mean 
 > "start" only.
 > Does anybody can start running again for example without prior stopping?
 
 Yes. Why not? :-)
 
 > Start must be start. Official documentation doesn't provide any 
 > explanation how to handle in a special way some particular _start up_ scripts.
 > Right way to applying firewall's rules over network explained very well for
 > /sbin/ipfw but not for /etc/rc.d/ipfw and I believe it is right.
 
 /etc/rc.d/ipfw is basically wrapper for /sbin/ipfw, so all rules apply.
 
 > I think it should be kept simple - start up script load initial firewall's
 > rule and after that one should handle reloading of firewall's rules with
 > own scripts by calling /sbin/ipfw that is intended exactly to do this kind
 > of actions.
 
 That's POLA issue. One should not break commands worked for years.
 Instead, fix bugs :-) And no, "/sbin/ipfw flush" does NOT break connections.
 Really, it does not deal with TCP connections at all.
 At application layer, sendto()/send() failure is NOT
 a legitimate reason to break session/connection, terminate user session
 and cause SIGHUP to be sent to users' processes.
 
 You may use one particular sshd(8) implementation having this misfeature
 to maintain the system over network, but it does not mean it's flaws
 should bring changes to firewall. You may also use other implementation
 possibly not having this bug. This one is in base system - well, that's
 another reason to fix bug where it is - inside sshd, but not touch
 perfectly working firewall.
 
 > Running command "start" twice is meaningless. If one want to reload 
 > firewall's rules with 
 > /etc/rc.d/ipfw then there should be implemented safe command "reload"
 > or something else, but I don't think it is a good idea.
 > /etc/rc.d/ipfw is a mechanism that generally 
 > control service - enable it or not.
 > If one need just reload firewall's rules it could be done by running
 > /etc/rc.firewall script enclosed in guarding script instead of 
 > "/etc/rc.d/ipfw start", something like this:
 > 
 > /bin/sh -T -c "trap 'exit 1;' 1 2 ; /bin/sh /etc/rc.firewall;"
 > 
 > or simply
 > 
 > /usr/bin/nohup /bin/sh /etc/rc.firewall
 > 
 > in case if /usr already mounted.
 
 That would work for pre-8 versions of FreeBSD but not anymore
 because of coscripts. So, running just /etc/rc.firewall
 to reload rules is not an option anymore.
 Only /etc/rc.d/ipfw start is right way for now.
 
 > Ian Smith <smithi@nimnet.asn.au> wrote:
 >> One of the reasons that people might want to run 'start' again when it's 
 >> already running is described in (at least) both of:
 > I'm sorry, but running twice '/etc/rc.d/ipfw start' isn't solution in that case.
 > I think the right solution is to fix logical bug and run natd first before 
 > loading firewall rules instead of running "start" command twice.
 > (BTW, it's impossible to run '/etc/rc.d/ipfw start' on boot twice,
 >  so it could be a solution)
 
 Here we may have a security issue. Firewall should be loaded
 before interfaces brought up. natd may depend on interfaces up and running
 to initialize itself properly. For example, it may need to know right MTU
 of interface (I can describe why it may need it in detail, if you wish).
 Basically, it means that firewall should support its own DIVERT rules
 configuration before natd is started (and it supports) and it means
 that natd should be started later than firewall, not before.
 The system behaves this way now and there are reasons for it.
 
 > Ian Smith <smithi@nimnet.asn.au> wrote:
 >> Nonetheless, Eugene's advice is worthwhile, ./ in PATH is never a good 
 >> idea when discussing security, which is what a firewall is all about.
 > Well, I completely agree with you and Eugene on that if it come to a 
 > general security. This is kind of topic, but you forget that some 
 > projects don't need to be opened to the wild internet, it could be an 
 > automatic stations in closed environment where using ./ in the PATH can 
 > simplify things a lot without any security issues.
 
 Just use telnet then :-) it won't break sessions AFAIR.
 
 > Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 >> "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.
 > Eugene, don't take my words as offense please, lets talk about technical
 > aspects only.
 > Do you reload MySql with '/usr/local/etc/rc.d/mysql-server start'?
 > I guess - no. The same with other services because meaning of word "start"
 > is to born new instance of something.
 > "/etc/rc.d/ipfw start" isn't exclusion, it should follow human's logic.
 > If one want to reload firewall's rules he/she need to implement command "reload".
 
 I'm not against implementing "reload". I'm strongly against breaking POLA
 and breaking working setups by prohibition of multiple "/sbin/ipfw start" calls
 for sake of someone's logic favour. Instead, one could fix real problem with sshd.
 
 > Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 >> It does not cause lockdown if used in right way, I do this all the time.
 > Instead of repeating many times about magic "right way" could you point me
 > to documentation where is this "right way" explained?
 
 See above.
 
 > Don't point me to ipfw(8) manual page again please because it describe 
 > "/sbin/ipfw" but isn't "/etc/rc.d/ipfw".
 > There is a big difference between them.
 
 But same rules apply and lead to success :-)
 
 > I didn't saw in the documentation a special 'right way' of using rc.d start up
 > scripts. May be I miss something, may be you.
 
 Well, you may consider documentation insufficient (I do not :)
 Then, feel free to submit patches for documentation but please,
 don't fix what ain't broken.
 
 > You can execute anyone scripts without any parameters in rc.d directory and it 
 > will show all available arguments that can be passed to scripts.
 > I didn't found anyone rc scripts that says it need to be used in a special
 > "right way".
 > There no and shouldn't be any special tricks to run start up scripts.
 
 There may be any kind of tricks depending on real task
 (all "tricks" should be documented, though), for example:
 
 - one should not blindly call rc.d script for natd with "restart" argument
 over NAT'ed connection, because THAT may really break TCP connection;
 - one should not blindly call rc.d script for routed with "restart" argument
 when it may destroy route it's using for pretty long time (RIP diverges slowly);
 - one should not blindly call rc.d script for amd/nfsd with "restart" argument
 when it's current directory resides on network-mounted file system;
 - et cetera, et cetera, et cetera (ipsec, netif, ...)
 
 > Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 >> 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.
 > Absolutely agree with you on that - "Disabling firewall is not an option" 
 > but reloading firewall's rules by employ "/etc/rc.d/ipfw start" isn't
 > an option too.
 
 Why not? It works when used right way, and worked for long time.
 
 > Eugene Grosbein <egrosbein@rdtc.ru> wrote:
 >>  >  Did you try all steps described in the "How-To-Repeat" section before replying?
 >> Yes. No problems here.
 > I bet you did it from system console or by enclosing "/etc/rc.d/ipfw start"
 > to surrounding guarding script, otherwise if you don't protect 
 > '/etc/rc.d/ipfw start' from interruption then first 
 > "ipfw -f flash" command will broke connection to the box and script
 > "/etc/rc.d/ipfw" will stop execution in a middle by leaving box inaccessible
 > over network.
 
 My first letter was written in reply to your PR having no words
 about running command over network. Or about what your "lock-down" means,
 kernel panic? kernel hang? shell process deadlock? I've seen so many
 weird effects with FreeBSD over time, so avoid attempts to use telepathy.
 
 Now you know how important it is to be exact in problem reports.
 
 And yes, I generally use screen(1) for remote sessions,
 so my connections do not break. And I always use output redirection
 for "/etc/rc.d/ipfw start" even for screen-based sessions.
 That's the safe and working way.
 
 Eugene Grosbein
>Unformatted:
