From owner-freebsd-stable Mon Jan 28 9:52:22 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 4C07C37B402 for ; Mon, 28 Jan 2002 09:52:16 -0800 (PST) Received: (from root@localhost) by mail.27in.tv (8.11.6/8.11.6) id g0SHqDU72576; Mon, 28 Jan 2002 12:52:13 -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 g0SHqBU72567; Mon, 28 Jan 2002 12:52:11 -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 12:52:12 -0500 (EST) Message-ID: <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> Date: Mon, 28 Jan 2002 12:52:12 -0500 (EST) Subject: Re: Firewall config non-intuitiveness From: "C J Michaels" To: In-Reply-To: <200201271757.g0RHvTF12944@midway.uchicago.edu> References: <200201271757.g0RHvTF12944@midway.uchicago.edu> 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 David Syphers said: > On Sunday 27 January 2002 11:27 am, M. Warner Losh wrote: >> Right now what I have works. You are changing the semantics of a >> security related feature of the system in such a way that after this >> change what I have will not work. I agree that your work around will >> allow me to easily correct things. However, if I fail to do so, I >> open my firewall up completely. To me, that's an unacceptible change >> in the API. > > You yourself said that you're doing things that "don't fit in well with > the current firewall paradigm." So they're hacks, and you shouldn't > expect them to work indefinitely. For every person like you, there > are probably ten like me, who in a state of ignorant bliss rebooted a > machine they were remotely admining with firewall_enable set to NO. > Imagine the surprise when I was completely locked out. As others have > pointed out this behavior is documented, but we must remember that a > variable name itself is the most important and immediate > documentation. And having a firewall load when firewall_enable is NO > is complete nonsense. Warner, Should not Everyone who tracks -STABLE be reading /usr/src/UPDATING?? _Especially_ those who have non-standard (hacked) configurations such as yours! I'd be quite disappointed if you didn't read your own work. :) That being said, I've been 'caught with my pants down' by not reading that file before... and that was no one's fault but my own. I can see this issue from both sides. One of the best things about FreeBSD is the fact that with the right knowledge you can do and change almost anything you want. Does that mean that your unusual configuration should be considered when changes are made to the OS? Yes. Does it mean that changes shouldn't happen? No. That's the point of the HEADS-UP messages on this list, and /usr/src/UPDATING. Both of which _everyone_ who tracks - STABLE should be following. 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. > > This change would affect security only for the people who are > knowledgeable enough to understand this weird variable in the first > place. This effect would be minimal. A default desktop install of > FreeBSD will enable Sendmail and inetd and have no firewall, and > you're worried about this security effect? He's worried about the security effect because it would take a working (assumed) secure machine, and make it insecure. Securing a FreeBSD system out of the box, because the user is too lazy to figure out how to do it on their own, is hand holding (let's not argue that out, in this thread please). Going through the trouble of locking it down afterward, and having the firewall spontaneously disappear is flat out breakage. So, on that note, I think we should not be making this change to -STABLE (at least, not yet). I do think this should be implemented in -CURRENT and later inclusion into the base system. And if/and when this change is implemented in -STABLE, a notice to FreeBSD-Security- Advisories@FreeeBSD.org would be a VERY good idea. Status-quo is not always good for business. > > -David > Center for Cosmological Physics > The University of Chicago -- 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