Date: Fri, 1 Feb 2002 17:16:33 -0500 From: "Benjamin P. Grubin" <bgrubin@pobox.com> To: "'Garance A Drosihn'" <drosih@rpi.edu> Cc: <freebsd-current@freebsd.org> Subject: RE: *_enable="YES" behavior is bogus Message-ID: <000d01c1ab6e$1e8f8900$080aa8c0@vinzclortho> In-Reply-To: <p05101415b880b7928804@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, I'm usually but a lurker, though I'd like to toss in my $.02 on this... > -----Original Message----- > From: owner-freebsd-current@FreeBSD.ORG > [mailto:owner-freebsd-current@FreeBSD.ORG] On Behalf Of > Garance A Drosihn > Sent: Friday, February 01, 2002 4:52 PM > To: Erik Trulsson; Paul Fardy > Cc: current@FreeBSD.ORG; stable@FreeBSD.ORG > Subject: Re: *_enable="YES" behavior is bogus > In this discussion, there have been two suggestions as to how > 'firewall_enable=no' should behave. > 1) if the firewall is compiled in the kernel, then "=no" > means that the firewall is blocking all packets, no > matter what other rules might be lying around. The > machine is completely locked down from network access > (ie, the present behavior). > or 2) no matter how the kernel is compiled, "=no" means the > machine acts as if there is no firewall installed. Ie, > it accepts all packets. No packets are blocked. The > machine is wide open. It strikes me that #2 is the clear winner in terms of implementation consistency. > I understand the first "error" (where the machine ends up completely > open) is not desirable. It is very very bad. However, I > think we can write some code to help out that user. That > user is extremely likely to be sitting at the console, and > they are extremely likely to want to log into that console, > and there is nothing which prevents them from logging in. We > can provide warning messages for that user, and they can > immediately fix the "error". I'm not sure why this would be considered not desirable or "bad" in any other way. When the kernel is first compiled with the firewalling code, it seem silly that anyone would, at that early point, consider themselves firewalled. Even your average knucklehead user that wants to use the firewalling code, and compiles a new kernel with it present (implying at least some level of technical proficiency in the first place) would not expect to render the network useless--or be protected--until some chain of events occurred. The proper thing (IMHO) is to leave the behavior of the box unchanged (unfirewalled) until a change is willfully implemented--as opposed to some functionality being added to the kernel, which should not really effect normal operations (obviously with some rather large exceptions). If the exceptions are a concern, it seems to me focus should be on the consistency of kernel configuration and how it relates to normal operations--not the rc files. Cheers, Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000d01c1ab6e$1e8f8900$080aa8c0>