Executive summary:

The [sic] fix in NetBSD's ip_fil is perceived by security-weenies
as a security flaw.

So, how about this: we add a hook to ip_fil'sn pseudo-device attach
routine, to turn on filtering, so those that rely on the old semantics
get it by default; and we add a config option that turns off that
call, so those who need to configure fail-open can do so.

Long, boring rationale follows.


>Jonathan Stone writes:
> Perry E. Metzger <perry@piermont.com> writes:
> >> Having to explicitly turn ip_filter *on* is a bug, in some environments.
> 
> >Indeed. You don't want packets to leak during bootup.
> 
> Yes, that's exactly what I meant (I forgot to say so explicitly).
> Thanks for clarifying it.

>I would suggest, btw, that "the right thing" is for machines with the
>IP filter code built in to not route *anything* (lets not forget
>source routes!) until the filtering has been properly established.

Jason Thorpe writes (in reply to an earlier message):

>Certainly _NOT_ in the form it was in before.  If you're going to do
>that (which I'd rather you not, but whatever), then please don't make
>it happen by sheer coincidence of namespace collision.


And from the NetBSD CVS logs for ip_fil.c:

[...]

>        - When main() calls (by sheer coincidence!) iplattach(),
>          the filter hook is established, and the IP Filter machinery
>          labeled as "initialized".  This causes all packets, whether or
>          not the user intents to use filter rules, to be passed to
>          the filter rule checker if "ipfilter" is configured into the
>          kernel.


>Fix:
>
>        - Rename iplattach()/ipldetach() to ipl_enable() and ipl_disable().
>
>        - Create a pseudo-device entry stub named ipfilterattach()
>          (NetBSD case) or iplattach() (all other).  This is a noop; none
>          of the machinery should be initialized until the caller expicitly
>          enables the filter with ipf -E.  Add a comment to note that.


Perry and I both thinkn the behaviour of ip_fil before rev 1.7 is
preferable. I think the change in behaviour introduced by rev 1.7
introduces a security bug.  The machine(s) I have set up as firewalls
use an older version of ipf.  Configuring ip_fil into a kernel blocks
all(?)  IP packets, until filters are explicitly added via ipf.  (I
use /etc/rc scripts that push the local filter rules into the kernel
before configuring any interfaces up.)

This ensures that there's *no* window in which packets can leak
through the firewall when it's booting.  Such a window is a bug.

It also provides a `fail-closed' model of operation: if you configure
IPF into the kernel of a router, the router doesn't send any packets
unless you explicitly configure it to.   If the ipf config gets
accidentally toasted, then the firewall router fails shut.
Both these are useful security features. I'd assumed they were
deliberately designed into ip_filter.  I would like them back.

I've already had someone deliberately overloading and crashing a
lesser, non-NetBSD switch/router box.  At boot time, that box lets any
packets through until it's up far enough to read filter rules and
install them.

So, I'll make a stronger statement than I did last time.  I would like
to revert ip_filter to give the old behaviour as the default: at
pseudo-device attach time, ipfil is enabled.  For those who really
want the current semantics, we can add a new config option that turns
off the pseudo-device attach-time enabling of _fil, giving the
``configured in but fail-open'' semantics that the NetBSD rev 1.7
provides.

Wearing my security-weenie hat, in ip_fil's pseudo-device attach
routine is exactly the appropriate place to put such a hook.

If anyone has a problem with doing this, let's discuss it.