From owner-freebsd-stable Tue Jan 29 11:49: 1 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 7067737B416 for ; Tue, 29 Jan 2002 11:48:44 -0800 (PST) Received: (qmail 14978 invoked by uid 0); 29 Jan 2002 19:47:45 -0000 Received: from pd9508836.dip.t-dialin.net (HELO mail.gsinet.sittig.org) (217.80.136.54) by mail.gmx.net (mp008-rz3) with SMTP; 29 Jan 2002 19:47:45 -0000 Received: (qmail 48623 invoked from network); 29 Jan 2002 19:34:01 -0000 Received: from shell.gsinet.sittig.org (192.168.11.153) by mail.gsinet.sittig.org with SMTP; 29 Jan 2002 19:34:01 -0000 Received: (from sittig@localhost) by shell.gsinet.sittig.org (8.11.3/8.11.3) id g0TJY1348619 for freebsd-stable@freebsd.org; Tue, 29 Jan 2002 20:34:01 +0100 (CET) (envelope-from sittig) Date: Tue, 29 Jan 2002 20:34:01 +0100 From: Gerhard Sittig To: freebsd-stable@freebsd.org Subject: Re: Summary: Problems and Proposals of firewall_enable (was: Re: firewall config (CTFM)) Message-ID: <20020129203401.H1494@shell.gsinet.sittig.org> Mail-Followup-To: freebsd-stable@freebsd.org References: <15445.37204.693732.376471@caddis.yogotech.com> <20020128150458.E10891-100000@charon.acheron.localnet> <15445.46625.765383.179068@caddis.yogotech.com> <20020128223911.GA7080@rhadamanth> <008001c1a877$091c2aa0$4011a8c0@whwurm.uniulm.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <008001c1a877$091c2aa0$4011a8c0@whwurm.uniulm.de>; from Siegbert.Baude@gmx.de on Tue, Jan 29, 2002 at 04:42:54AM +0100 Organization: System Defenestrators Inc. 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 Tue, Jan 29, 2002 at 04:42 +0100, Siegbert Baude wrote: > > Problem 4: > Maybe only my ignorance, because I never did it: How do I find out > before reboot, if IPFIREWALL is compiled in my kernel, if the relevant > config file is not there, e.g. on very stripped installations, where > make buildworld/-kernel is done on external machines? We all know the > lack of documentation in the real admin's world. Verbal heritage between > admin generations is sometimes suboptimal, too. Is this the moment where we have to ask for INCLUDE_CONFIG_FILE in GENERIC once more? Is the public demand or "would be nice" judgement big enough to make me sit down and provide a patch? I know it's not a one line change. GENERIC should get the option added while release build scripts and maybe picobsd stuff don't like bloat like "nice" string tables in executables for the users' pure pleasure but without essential functionality. [ should this be worth a new thread feel free to change the subject, it's in no way connected to the firewall_enable discussion :) ] > Long term solution #2: Rethink the variables with having two different > methods in mind, i.e. ipfw and ipfilter. > > Should be in the line of (capital letters denote defaults): > firewall_functionality on/OFF > firewall_method ipfilter/IPFW This implies that ipf and ipfw are mutually exclusive. Although rc.conf(5) suggests to use one of them, people reportedly run both of them alongside without any problems. They use ipf for packet filtering tasks while ipfw does traffic shaping (bandwidth limiting). This and the fact that both filters come into play at totally different times and places in the boot sequence won't let you combine these two aspects (easily or without too much code of spaghetti shape). Even if ipfw invocation gets moved upwards to where ipf gets initialized there is still the situation where both are enabled at the same time. There might be a "filter_enable" setting with an "ON/OFF" range and a "filter_systems" setting with a *list* of implementations to configure. But then an empty list could easily take the place of the OFF switch ... And I wouldn't stick too much with the "we only have ipfw or ipf" constraint in mind. We might have OpenBSD's pf some day in the near future, too. :) > firewall_ruleset UNKNOWN #see /etc/rc.firewall * > firewall_ruleset_load on/OFF #always OFF if ruleset==UNKNOWN * This one is strictly ipfw related (ATM?). Although one could have misused the firewall_ruleset to hold what is in ipfilter_rules now. But again, see above: ipfw and ipf can happily run at the same time. > firewall_kernel_overrule ON/off #will overrule firewall_functionality > #if IPFIREWALL is compiled in kernel If this boils down to a single sysctl setting than it probably is better done in sysctl.conf. ISTR that there is a general move towards this direction (to eliminate switches which only do / result in a "sysctl $MIB=$VAL"). BTW: Is the above your notation for ON to be the default? This is in contrast to what the prose says. :> Or do I misread it and it means "leave what's already the kernel's behaviour no matter what the rc.conf variables specify"? I'm a little confused. Some "disable_loaded_filter" might be better. But see the above comment on "if it's a mere sysctl ...". > *: This is in accordance to Warner's point, that compiled in kernel > rules, shouldn't be touched unless explicitly wanted. This should be > true not only for IPFIREWALL but also for IPFIREWALL_DEFAULT_TO_ACCEPT. AMEN! :) I considered this to be a common FreeBSD or UNIX in general policy: Don't guess what could have been meant but instead stupidly(id? there certainly is a better word but I'm not a native speaker) following the admin's / user's command. The human in control is to blame for all the "issues" which result from wrong commands -- but in return gets full control of what happens. > [ ... ] It is > better to keep things in one place, so we need this one instead of some > sysctl tweaking in other places. [ ... ] Good point. But I thought I had spotted a movement of eliminating "simple sysctl wrappers". Unless I'm mistaking ... > Has the discussion to be continued on the stable list? -chat? :) -security? -hackers? 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message