From owner-freebsd-current Fri Feb 1 14:17:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 3C7BB37B400 for ; Fri, 1 Feb 2002 14:16:46 -0800 (PST) Received: (qmail 18585 invoked from network); 1 Feb 2002 22:16:45 -0000 Received: from unknown (HELO vinzclortho) ([66.92.70.186]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 1 Feb 2002 22:16:45 -0000 From: "Benjamin P. Grubin" To: "'Garance A Drosihn'" Cc: Subject: RE: *_enable="YES" behavior is bogus Date: Fri, 1 Feb 2002 17:16:33 -0500 Message-ID: <000d01c1ab6e$1e8f8900$080aa8c0@vinzclortho> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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