Date: Sun, 27 Jan 2002 22:09:41 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: FreeBSD-gnats-submit@freebsd.org Subject: conf/34355: [PATCH] rc.conf comment misleading (firewall_enable) Message-ID: <20020127220941.D1494@shell.gsinet.sittig.org>
next in thread | raw e-mail | index | archive | help
>Number: 34355
>Category: conf
>Synopsis: [PATCH] rc.conf comment misleading (firewall_enable)
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: doc-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Jan 27 13:30:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Gerhard Sittig
>Release: FreeBSD 4.4-STABLE i386
>Organization:
System Defenestrators Inc.
>Environment:
a FreeBSD system with ipfw
>Description:
This PR is triggered by a thread in -stable coming up these days
which led to the "Firewall config non-intuitiveness" subject
(sorry, I deleted most of the thread since right from the start
it screamed "pilot error"). It all started like this: A newbee
user built a kernel of his own by adding the IPFIREWALL setting
to a GENERIC template. Setting the firewall_enable variable in
rc.conf to "NO" made him think this would *disable* the filter
which defaults to denying everything.
While LINT (or NOTES respectively) has an explicit warning in it
# WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any"
# and if you do not add other rules during startup to allow access,
# YOU WILL LOCK YOURSELF OUT. It is suggested that you set firewall_type=open
# in /etc/rc.conf when first enabling this feature, then refining the
# firewall rules in /etc/rc.firewall after you've tested that the new kernel
# feature works properly.
and "man 5 rc.conf" says
firewall_enable
(bool) Set to ``YES'' to load firewall rules at startup.
If the kernel was not built with IPFIREWALL, the ipfw ker-
nel module will be loaded. See also ipfilter_enable.
(where the first sentence is the only relevant one but I cited
the whole paragraph for the variable), the comment in rc.conf
seems to be a little misleading:
firewall_enable="NO" # Set to YES to enable firewall functionality
>How-To-Repeat:
Hardconfigure(id?) ipfw into your kernel, leave the default
policy at denial, leave firewall_enable at "NO" -- while the
machine might have configured network interfaces no packet will
pass the filter.
>Fix:
The patch below brings the comment in line with the other pieces
of documentation as well as the long term FreeBSD admins'
expectations (the latter is how I read the email thread and
what I gathered myself from using FreeBSD and looking at its
rc scripts at different occasions).
Index: etc/defaults/rc.conf
===================================================================
RCS file: /CVSREPO/FreeBSD/src/etc/defaults/rc.conf,v
retrieving revision 1.136
diff -u -r1.136 rc.conf
--- etc/defaults/rc.conf 2001/12/29 19:42:54 1.136
+++ etc/defaults/rc.conf 2002/01/27 20:01:59
@@ -48,7 +48,7 @@
nisdomainname="NO" # Set to NIS domain if using NIS (or NO).
dhcp_program="/sbin/dhclient" # Path to dhcp client program.
dhcp_flags="" # Additional flags to pass to dhcp client.
-firewall_enable="NO" # Set to YES to enable firewall functionality
+firewall_enable="NO" # Set to YES to load firewall rulesets
firewall_script="/etc/rc.firewall" # Which script to run to set up the firewall
firewall_type="UNKNOWN" # Firewall type (see /etc/rc.firewall)
firewall_quiet="NO" # Set to YES to suppress rule display
What has been proposed in the thread, too, by those who were
surprised by the system's behaviour went along the lines of
'firewall_enable="NO" means "turn off firewall functionality"' --
which I'm not going to buy.
First: There's no way of learning whether the NO setting came
from explicitely setting the variable to NO or if it still was
set to NO by not overriding the default value. So it's hard to
decide for the rc script what's in /etc/rc.conf (and other local
scripts) and what's not (i.e. what's the default).
Second: The confusion came from explicitely including a packet
filter into the kernel which was configured to not pass any
packet. When all the available documentation stated what the
resulting behaviour would be. In my book either does the comment
in rc.conf not count as a reference but is a mere hint -- it's
simply too short to summarize or even mirror the full doc. And in
case it counts for those who want to pick nits, the opposite of
"do enable" is "do not enable" (and _not_ "do disable"). A look
at the boot script, a look at the authoritative manpage as well
as reading the comment right next to the IPFIREWALL setting when
configuring the kernel -- an advanced task for those who should
know what they do -- would have clarified things.
Third: I wouldn't like the current behaviour to change to
something more open just because of such a wild assumption ("when
I put a strict filter into the kernel and don't configure it, it
should be opened up totally"). Opening up huge gaping holes
towards the network -- especially on machines where the admin
explicitely included a filter into the kernel -- definitely is
a wrong approach. This kind of action (opening up something)
*always* should be done only upon the admin's explicit wish.
Plus reinterpreting this security relevant setting would break
the existing installations for the pure benefit of those who
neglect to read the available comments when configuring a
kernel.
Fourth: There's no need to reinterpret the existing knob nor is
there a need to introduce a new setting of DISABLE for the
firewall_enable variable. All of this can be achieved by the
existing settings for "do load a ruleset" and "load this very
ruleset". Should having a filter and loading a totally open
ruleset be considered overkill than that's a completely different
story (and might be circumvented by editing rc.firewall to insert
a "disabled" case besides the "open" one to do the sysctl stuff
or by adding the setting to sysctl.conf or having a local rc
script to adjust things which deviate from the normal FreeBSD
way). But I would (like to) always see the firewall_enable knob
as "do configure this aspect" and setting or leaving it to NO
should always read "leave it alone, please". Every other range
of answers (do this, do that, do nothing) needs a different
notation from _enable (like *_type).
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020127220941.D1494>