From owner-freebsd-current Fri Feb 1 21:43: 2 2002 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2DE7D37B421 for ; Fri, 1 Feb 2002 21:42:41 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g125geo45501; Fri, 1 Feb 2002 22:42:40 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g125gbL08161; Fri, 1 Feb 2002 22:42:37 -0700 (MST) (envelope-from imp@village.org) Date: Fri, 01 Feb 2002 22:42:19 -0700 (MST) Message-Id: <20020201.224219.62370052.imp@village.org> To: drosih@rpi.edu Cc: current@FreeBSD.ORG Subject: Re: *_enable="YES" behavior is bogus From: "M. Warner Losh" In-Reply-To: References: <5F46C986-16DB-11D6-8CEC-00039359034A@mac.com> <20020201173641.GA48397@student.uu.se> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 In message: Garance A Drosihn writes: : 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. : : If the user *expects* 1, but we actually implement 2, then the : machine is wide-open when they did not expect that. My position : is that we can *easily* do something to help that person : immediately realize that they did not get what they expected. : : If the user *expects* 2, but we implemented 1, then the machine : is locked down. If the user is not sitting at the console of : the machine, then there is absolutely nothing which can be done : (from a coding perspective) to help that person out. They must : have a keyboard and monitor on that machine, and they must go : to the machine and login via that console. The rational for #1 being implemented now is that all security features, when specially enabled (which you had to do to compile the kernel with ipfw in it) must fail "safely." Safely is defined as being more restrictive than less. #2 is less. That's the whole reason we do this. But I think this is going to be one of those threads that lasts forever and then nothing happens because they end in deadlock. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message