From owner-freebsd-stable Sun Jan 27 16:54:43 2002 Delivered-To: freebsd-stable@freebsd.org Received: from star.sstec.com (adsl-216-102-148-67.dsl.lsan03.pacbell.net [216.102.148.67]) by hub.freebsd.org (Postfix) with ESMTP id CE6EF37B404 for ; Sun, 27 Jan 2002 16:54:34 -0800 (PST) Received: from comm.sstec.com (comm.sstec.com [192.168.74.10]) by star.sstec.com (8.11.6/8.11.6) with ESMTP id g0S0una80077; Sun, 27 Jan 2002 16:56:49 -0800 (PST) (envelope-from fbsd@sstec.com) Message-Id: <5.1.0.14.2.20020127150544.00ac95c0@mail.sstec.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 27 Jan 2002 16:30:11 -0700 To: Patrick Greenwell , Gerhard Sittig From: "John R. Long" Subject: Re: Firewall config non-intuitiveness Cc: stable@FreeBSD.ORG In-Reply-To: <20020127134511.Q81780-100000@rockstar.stealthgeeks.net> References: <20020127220923.B1494@shell.gsinet.sittig.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 I have to go along with common sense and logic with this one. I was once burnt by it about 2 years ago. I compiled it in and set it to NO in .rc and nothing going thru. Strange, NO means no right?, it is a control knob to the kernel so NO must disable it right?. And disabled means the same as not in there right? If it means something else then say so clearly. I read this as allow "# firewall_type=open in /etc/rc.conf when first enabling this feature" similarly "firewall_enable="NO" means allow also. This problem cost me several hours of work, I was thinking that the compile was wrong because it did not make any sense. I say NO and it is dead so I boot GENERIC w/o firewall it works therefore the compile must have borked it. Recompile, tweak etc... LINT was/is Not comprehensive nor clear on that point! Just one of those things I guess, forget it for now. This thread brings up that damn problem of days past and that it was Not me. Everyone is new to Freebsd at some time but this goes beyond that, It should make common sense and not be an illogical nightmare. Say what you mean and be coherent about it. John R. Long sstec.com At 03:50 PM 1/27/2002, Patrick Greenwell wrote: >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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message