From owner-freebsd-stable Sun Jan 27 14:50:57 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rockstar.stealthgeeks.net (h-66-134-120-173.LSANCA54.covad.net [66.134.120.173]) by hub.freebsd.org (Postfix) with SMTP id 2F22737B416 for ; Sun, 27 Jan 2002 14:50:51 -0800 (PST) Received: (qmail 82502 invoked by uid 1001); 27 Jan 2002 22:50:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Jan 2002 22:50:50 -0000 Date: Sun, 27 Jan 2002 14:50:50 -0800 (PST) From: Patrick Greenwell To: Gerhard Sittig Cc: stable@freebsd.org Subject: Re: Firewall config non-intuitiveness In-Reply-To: <20020127220923.B1494@shell.gsinet.sittig.org> Message-ID: <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 27 Jan 2002, Gerhard Sittig wrote: > I filed a PR which does adjust the rc.conf comment (I understand > that LINT resp. NOTES as well as "man 5 rc.conf" both told the > originator of the thread what would happen while rc.conf was too > short and not authoritative enough a source to stop him from > shooting into his foot). I didn't address this issue earlier because I was more concerned with having something called "firewall_enable" do something that made sense when it was set to no. However, since you along with a couple of others have made the claim that this mislabled behavior is well-documented, I'd like to point out why I believe you are mistaken. Here's the relevent "documentation" that has been mentioned: From LINT: # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" # and if you do not add other rules during startup to allow access, # YOU WILL LOCK YOURSELF OUT. It is suggested that you set # firewall_type=open in /etc/rc.conf when first enabling this feature, # then refining the firewall rules in /etc/rc.firewall after you've tested # that the new kernel feature works properly. See anything in there about the firewall_enable variable? Anything that says something along the lines of "the firewall_enable variable has no effect if set to no?" While we're on the subject, the above documentation is incomplete as it fails to mention that you need to set firewall_enable to yes in order for the rc.firewall script to be executed(if I'm reading /etc/rc.network correctly.) The results of following the documentation outlined in LINT as written is that you'd still be locked out of your box. and here's the info from the rc.conf man page firewall_enable (bool) Set to ``YES'' to load firewall rules at startup. If the kernel was not built with IPFIREWALL, the ipfw kernel module will be loaded. See also ipfilter_enable. See anything in there about setting firewall_enable to "no"? So much for well-documented behavior. Really, I'm just arguing for doing something that makes sense, and the current behavior does not qualify, regardless of how long it's been understood to be broken that way. Even if this behavior were adequately documented, which it isn't, it's extremely user-unfriendly to have no mean yes. At this point I'm rather reticent to even bother submitting anything to the "security officer" role as Warner has indicated that he's part of that role and will speak out against it in the name of security. I'm not a member of the inner circle, just a long-time user who saw some confusing behavior and thought that there was an opportunity to fix it. I'll go tilt at some other windmills now. :-) /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell Stealthgeeks,LLC. Operations Consulting http://www.stealthgeeks.net \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message