From owner-freebsd-stable Mon Feb 26 07:38:19 1996 Return-Path: owner-stable Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA25648 for stable-outgoing; Mon, 26 Feb 1996 07:38:19 -0800 (PST) Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA25640 Mon, 26 Feb 1996 07:38:15 -0800 (PST) Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id IAA29287; Mon, 26 Feb 1996 08:40:53 -0700 Date: Mon, 26 Feb 1996 08:40:53 -0700 From: Nate Williams Message-Id: <199602261540.IAA29287@rocky.sri.MT.net> To: Poul-Henning Kamp Cc: michael butler , stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) In-Reply-To: <11364.825341183@critter.tfs.com> References: <199602261228.XAA07877@asstdc.scgt.oz.au> <11364.825341183@critter.tfs.com> Sender: owner-stable@freebsd.org Precedence: bulk Poul-Henning Kamp writes: > > If you ^C your way to a shell prompt, there's a single rule that's in the > > firewall list saying "deny all from any to any". Courtesy of the same recent > > brain-damage in ipfw(8), you can't delete this rule either ("setsockopt > > failed"). > > If you call this "brain-damage" then you quite clearly don't need IPFW. I understand that it's there to stop a race condition where folks can 'get into' the system before the FW rules are brought in. However, ... > > I suspect the very same problem in -current. > > > > The only workaround I can think of is to add "ipfw addf accept .." > > statements _prior_ to the running of ifconfig in netstart .. theory as yet > > untested .. > > This is all correct, designed that way, and it is the way it should work, > according to all material I have on the subject. > > If you have IPFW in your kernel, you don't want it to pass any packets > you haven't approved in your filters. > > QED: Setup your filters before anything gets passed. I can't do this on my box at all. It's a PPP connection, and *all* of the filtering is done on my PPP interface, which can vary depending on incoming calls. So, by having a default 'global' firewall entry I have a couple problems. 1) There is no established way to have it be on a per-process. This is *bad* news for me since my PPP box is also my DNS/router. I can't wait for my PPP connection to come up before I add entries, and I want all of my local machines to have access to *everything* on my router box. 2) There is no established method for adding IPFW entries in FreeBSD. If we are going to make this the default method, I think we need some hooks in /etc/netstart added to make this work. 3) The code -stable is un-documented and incomplete w/regard to -current. The documentation in -stable hasn't been updated yet. Here is the last entry for the ipfw.8 man-page. revision 1.7.4.5 date: 1996/02/23 15:28:38; author: phk; state: Exp; lines: +2 -0 Make ipfw handle the new kernel stuff. Put notice in man-page that it doesn't match reality right now. - But there have been commits since this time to the man-page, so I'm assuming that documentation has been written to document the new functionality. > Wrt to the rule #65535 "deny all from any to any", then you are correct, > you cannot delete it. It represents the default policy of "anything not > specifically allowed, is banned. While I understand why (see above), I still don't think this should be the 'global' default behavior. It should be applied on a specific interface since every gateway must have 2 interfaces, and only one will need the 'block everything' rule. Yes, I understand that I can add a 'open up everything' rule on my ethernet, but it'll also be necessary for all of my incoming PPP/SLIP connections. Also, how does this affect the PPP/SLIP startup code? Can a connection be established with the new IPFW code in place? > If you want to dispute this design, then please find at least one textbook > or capacity in the area who agree with you first, that will save a lot of > my time. I will dispute the design in that the current implementation *increases* the liklihood of errors due to lack of documentation and flexibility. The former may be the cause of the latter, but it's still a great cause of concern. Nate