Date: Mon, 26 Feb 1996 08:51:22 -0700 From: Nate Williams <nate@sri.MT.net> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: michael butler <imb@scgt.oz.au>, stable@freebsd.org, current@freebsd.org Subject: Re: -stable hangs at boot (fwd) Message-ID: <199602261551.IAA29317@rocky.sri.MT.net> In-Reply-To: <11445.825342415@critter.tfs.com> References: <199602261341.AAA09032@asstdc.scgt.oz.au> <11445.825342415@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I call it "brain-damage" to render a machine unbootable because it
> > can't "see" it's _own_ interfaces. AFAIK, firewalls by default
> > prevent packets passing _through_ them but are themselves permitted
> > to talk to anything they have a route to (the previous behaviour
> > with a default policy of "deny"). A direct connection (interface in
> > the same box) constitutes having a "route to"
>
> Well, this happens to be your view. I know machines where IPFW are being
> used to restrict what users on the machine can do, this is only possible
> if you filter >ALL< traffic, to and from the machine.
This is a policy decision which is *now* the default policy for
*everyone*.
> The IPFW is not a policy, it's a tool to implement policies. As such it
> needs to be able to implement the widest possible range of policies.
It is capable of filtering all traffic into and out of a machine before
w/out the the default rule. After thinking about the ramifications of
this, I'm beginning to swap more towards the side of keep it more useful
and document the heck out of it. Anyone who is using firewall software
better be intimately knowledgable about what they are doing. If we
document (there's the icky word again) the known problems with the
current system w/out the obnoxious default policy (notably the race
condition), then we are better off than by making the system unusable by
a # of folks.
> > Further, there are no hints whatsoever in the current rc, sysconfig,
> > netstart, et al to indicate that this (current condition) is the problem.
> > Even if this (IMHO unusual) behaviour was documented it wouldn't be so much
> > of a problem,
>
> No, this is still on it's way.
>
> You should be on -committers if you run -stable or -current. If you were,
> you would have seen it.
I am on both, but the code in -stable is different from the code in
-current, so the documentation is not up to snuff.
Here's commit information for just ip_fw.c:
----------------------------
revision 1.31
date: 1996/02/24 00:17:32; author: phk; state: Exp; lines: +49 -45
The new firewall functionality:
Filter on the direction (in/out).
Filter on fragment/not fragment.
----------------------------
revision 1.30
date: 1996/02/23 20:11:37; author: phk; state: Exp; lines: +6 -1
I overlooked this one.
----------------------------
revision 1.29
date: 1996/02/23 15:47:49; author: phk; state: Exp; lines: +290 -719
Big sweep over the IPFIREWALL and IPACCT code.
Close the ip-fragment hole.
Waste less memory.
Rewrite to contemporary more readable style.
Kill separate IPACCT facility, use "accept" rules in IPFIREWALL.
Filter incoming >and< outgoing packets.
Replace "policy" by sticky "deny all" rule.
Rules have numbers used for ordering and deletion.
Remove "rerorder" code entirely.
Count packet & bytecount matches for rules.
Code in -current & -stable is now the same.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And there have been apparently a significant commit to -current which
hasn't been done to -stable at which point the documentation to -current
was updated.
----------------------------
revision 1.14.4.5
date: 1996/02/23 20:10:52; author: phk; state: Exp; lines: +6 -1
Overloooked this one.
----------------------------
revision 1.14.4.4
date: 1996/02/23 15:26:03; author: phk; state: Exp; lines: +381 -694
Big sweep over the IPFIREWALL and IPACCT code.
Close the ip-fragment hole.
Waste less memory.
Rewrite to contemporary more readable style.
Kill separate IPACCT facility, use "accept" rules in IPFIREWALL.
Filter incoming >and< outgoing packets.
Replace "policy" by sticky "deny all" rule.
Rules have numbers used for ordering and deletion.
Remove "rerorder" code entirely.
Count packet & bytecount matches for rules.
----------------------------
According to the -stable commit to ipfw(8) (see previous email) the
documentation is invalid. Short of perusing the code (which IMHO
shouldn't be necessary for -stable bits) there is no valid documentation
for the code in -stable. This is unacceptable, since we are telling
folks that -stable contains code that should be run in production
systems.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602261551.IAA29317>