From owner-freebsd-stable Mon Jan 28 12:19:17 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by hub.freebsd.org (Postfix) with ESMTP id D472737B416 for ; Mon, 28 Jan 2002 12:19:00 -0800 (PST) Received: (from root@localhost) by mail.27in.tv (8.11.6/8.11.6) id g0SKIsn75272; Mon, 28 Jan 2002 15:18:54 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 27in.tv (roc-66-24-112-7.rochester.rr.com [66.24.112.7]) by mail.27in.tv (8.11.6/8.11.6av) with SMTP id g0SKIrU75262; Mon, 28 Jan 2002 15:18:53 -0500 (EST) (envelope-from cjm2@earthling.net) Received: from 216.153.202.59 (SquirrelMail authenticated user cjm2) by www1.27in.tv with HTTP; Mon, 28 Jan 2002 15:18:53 -0500 (EST) Message-ID: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> Date: Mon, 28 Jan 2002 15:18:53 -0500 (EST) Subject: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] From: "C J Michaels" To: In-Reply-To: <20020128192930.GA86720@student.uu.se> References: <20020128192930.GA86720@student.uu.se> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.5 [cvs]) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by AMaViS perl-11 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 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). This should suit the needs of just about every person who has been involved in this discussion. Please follow up with comments, esp if I missed something. Thanks for you time. -- Chris "I'll defend to the death your right to say that, but I never said I'd listen to it!" -- Tom Galloway with apologies to Voltaire To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message