Date: Mon, 28 Jan 2002 13:51:20 -0700 (MST) From: "M. Warner Losh" <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] Message-ID: <20020128.135120.11184725.imp@village.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv>
"C J Michaels" <cjm2@earthling.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020128.135120.11184725.imp>