From owner-freebsd-stable Mon Jan 28 11:29:50 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by hub.freebsd.org (Postfix) with ESMTP id C4CC337B404 for ; Mon, 28 Jan 2002 11:29:36 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailg.telia.com (8.11.6/8.11.6) with ESMTP id g0SJTZn26478 for ; Mon, 28 Jan 2002 20:29:35 +0100 (CET) Received: from falcon.midgard.homeip.net (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id UAA00175 for ; Mon, 28 Jan 2002 20:29:34 +0100 (CET) Received: (qmail 86777 invoked by uid 1001); 28 Jan 2002 19:29:31 -0000 Date: Mon, 28 Jan 2002 20:29:31 +0100 From: Erik Trulsson To: C J Michaels Cc: charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@freebsd.org Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128192930.GA86720@student.uu.se> Mail-Followup-To: C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@freebsd.org References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> User-Agent: Mutt/1.3.25i 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 On Mon, Jan 28, 2002 at 12:52:12PM -0500, C J Michaels wrote: > > Personally, I think the way things are now is highly non-intuitive. Having > firewall_enable="NO" disable the firewall would make sense to someone who > does not yet have alot of knowledge about that portion of the system. And > quite frankly, to myself. > > I also agree 100% that, if someone adds IPFIREWALL to their kernel config > (or anything for that matter) they should be aware of the consequences of > that action. On the other hand, there are quite a number of how-to > documents, that tell people to do exactly that to configure a firewall on > FreeBSD. Note that "do not enable firewall" (which is implied by firewall_enable="NO") is *not* equivalent to "disable firewall". So, no, I don't think it is obvious that firewall_enable="NO" should disable the firewall if it already was enabled by adding IPFIREWALL to the kernel config. (Nor is it obvious that it will not be disabled.) As other people have noted before firewall_enable really should be a tri-state variable with the possible values: "YES" -- enable firewall "NO" -- do not enable firewall "DISABLE" -- disable firewall (The values might instead be "ENABLE", "USE_DEFAULT" and "DISABLE" which might be more intuitive.) (The last possible function, "invert state of firewall", is not very useful IMO.) For a reason why having firewall_enable="NO" disable the firewall can be ha bad idea consider the following scenario: Assume a machine with IPFIREWALL set in the kernel config and with firewall_enable="YES" in /etc/rc.conf. Now imagine that the admin screws up when upgrading the machine or changing the configuration and accidentally removes the firewall_enable="YES" line from /etc/rc.conf. When rebooting the machine, since firewall_enable is not set in /etc/rc.conf, the default value of that variable would be used which is "NO". With the current behaviour what would happen then is that the firewall would default to "deny all". This would probably be noticed very quickly since no packets will get through the firewall. Annoying (for a remote machine possibly very annoying and troublesome) but not a security problem. With the proposed change (disabling the firewall if firewall_enable="NO") what would happen is that the firewall machine would be wide open. This might not be noticed for some time and is definitely a security problem. So, while I agree the the current situation might not be quite as intuitive as it might be changing the behaviour of firewall_enable="NO" to actually disabling the firewall is, IMO, *not* the right way to fix this. (If the admin went to the trouble of adding IPFIREWALL to the kernel, the default behaviour should be to not disable it.) -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message