From owner-freebsd-stable Mon Jan 28 12:51:57 2002 Delivered-To: freebsd-stable@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0221737B400 for ; Mon, 28 Jan 2002 12:51:50 -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 g0SKpao19669; Mon, 28 Jan 2002 13:51:37 -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 g0SKpZx12569; Mon, 28 Jan 2002 13:51:36 -0700 (MST) (envelope-from imp@village.org) Date: Mon, 28 Jan 2002 13:51:20 -0700 (MST) Message-Id: <20020128.135120.11184725.imp@village.org> To: cjm2@earthling.net Cc: stable@freebsd.org, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] From: "M. Warner Losh" In-Reply-To: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> References: <20020128192930.GA86720@student.uu.se> <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> 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-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> "C J Michaels" writes: : 1st off.. : Warner: Sorry for sending my earlier reply w/o reading the whole thread. : Jacques: Would the proposed change (below) still require approval from the : security officer? : : ====== : : In light of all the recent ipfw hubub, I think I have a equitable solution : for all. Most or all of these have been suggested by others, I am just : trying to put them into one consice proposal. : : This thread has really gotten out of control and I think, forked in the : wrong direction. Instead of changing the functionality of the knob, all we : should need to do is properly document the knob and (almost) everyone : should be happy. : : This is the situation as I see it: : 1. We have an option that is not intuitive to all, it's not even : intuitive to many, even Nate. :) : 2. Said knob has the potential to seriously degrade system security : if changed. : 2a. System security takes precidence to usability, at least with : something that can this seriously break a config. : 3. We have unclear documentation about said knob. : : I am going to propose the following changes: : 1. We rename the option to something like "firewall_load_rules" or : "firewall_enable_rules", etc... Someone else can come up with a : short yet more concise variable name. : 2. We grandfather in the old option of "firewall_enable" so existing : rc.conf(5)'s are not broken. : 2a. Obviously we are going to have a default in /etc/default/rc.conf : for this newly renamed knob. We should, in cases where : firewall_enable="YES", it should override the new knob. : 2b. At some point in the future, with much fanfare and documentation, : and probably messages to FreeBSD-Security-Advisories we phase out : the old option completely, so we don't keep a kludge in the system. : 3. Document said change in /etc/defaults/rc.conf and in rc.conf(5). : 4. Explicitly document the effect of both "YES" and "NO" in rc.conf(5). How about renaming things a little more: ipfw_load_rules={yes,no} ipfw_disable_firewall={yes,no} ipfw_kldload={yes,no} ipfw_load_rules would load ipfw rules, like firewall_enable does now. ipfw_disable_firewall breaks symetry on purpose, and would disable all ipfw functionality that may be compiled into the kernel. Since this is fairly explicit, it can default to no and if someone sets it to yes, they know what to expect without the current ambiguous situation (yes, it is ambiguous, which is why we're arguing about it). I know that all other foo_enable stuff uses the form foo_enable, but that is ambiguous in this case since there are two parts. ipfw_kldload would allow kld the ipfw.ko module. It would default to no. Note: There would be no ipfw_enable. We should then deprecate firewall_*. We have two firewall systems in the kernel (ipfw and ipfilter). We shouldn't be favoring one by calling it firewall and the other as ipfilter. No one is advocating disabling ipfilter also when firewall_enable=NO, are they? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message