Re: ipfw - default to accept + bootp = confusion.

On Thursday, August 7, 2003, at 02:23  AM, Juli Mallett wrote:

> * James Quick <jq_at_quick.com> [ Date: 2003-08-07 ]
> 	[ w.r.t. Re: ipfw - default to accept + bootp = confusion. ]
>>
>> On Thursday, August 7, 2003, at 12:22  AM, Juli Mallett wrote:
>>
>>> Does someone have any idea what approach to take for the following
>>> scenario?  I'm leaning towards a compile time failure, or an
>>> informative
>>> panic at the beginning of bootp...
>>>
>>> You have IPFIREWALL, but not the default to accept option, and you 
>>> have
>>> BOOTP.  The BOOTP stuff will fail in sosend with EACCESS 
>>> (informatively
>>> printed as "13"), because of IPFW, and this may be slightly 
>>> non-obvious
>>> to people who haven't dealt with early ipfw interference before.
>>>
>>> If not compile time failure / panic, I'd say probably we want some 
>>> way
>>> to notify a user in general of ipfw stopping pre-init operation, but 
>>> I
>>> don't want to add the concept of runlevels, and don't know if there's
>>> anything there currently to do detection of if we've hit that point
>>> yet.
>>
>> If the default rule controlled by IPFIREWALL_DEFAULT_TO_ACCEPT,
>> default_rule.cmd[0].opcode, were made accessible via a sysctl.
>> then bootp could check it and produce an informative message.
>> Or, if possible try to insert a rule into the kernel restrictive 
>> enough
>> to
>> be safe.  On the one hand it's a firewall, and you don't want to be
>
> It's entirely easy/possible to add such, but I'd rather not have a
> dumb sysadmin blame me for their firewall supposedly getting
> punctured.  If you have BOOTP on a box, defaulting to DENY is insane.
> Does that mean I want to just *change* things at runtime?  No.  I'd
> rather prevent any foot-shooting of any form.

Given the current implementation, the situation is "insane".  However,
In a wider context, it might be worth looking at the configuration 
decisions
in terms of allowable site policy, rather than dismissing the 
combination
as worthless.  Regarding foot-shooting, I agree that bypassing the deny
rule to finish booting needs to be analyzed carefully and made explicit 
to
the user, through a combination of documentation and/or user 
intervention.
and/or documentation.  I believe however, that the point is largely 
moot.
A foot is already bloody at this point, isn't it?

Given the current behavior, the critical path is the conjunction of 
three
or four events.  Only one of which is compilation.  Complaining or 
halting
during compilation, or requiring additional action to get  a quiet 
compile
seem ill-advised.  They add complexity to the common path in order to
flag a possible error which could only occur in the context of several 
other
independent (and uncommon) events.  To reach this point the kernel has 
to be:
	1. Installed as a resource on a bootpd or tftpd server.
	2. Loaded by a system configured to boot it, because:
		a. They are diskless
		b. They suffered a loader failure from local disk and are
		attempting a more graceful failure by booting from the network.

The "insanity" of the configuration, is thus dependent both, on a
number of configuration choices outside of the kernel, and the
current implementation, which has no choice but to fail.

I think this is best viewed as a matter of defining allowable policy.
Making a decision about how to handle this situation, has direct impact 
on
the choices available to the end-user in defining site-wide 
architecture.

In the default configuration, sites have the choice of either using 
diskless
workstations, or configuring hosts with local disk to perform a network
boot after an initial failure.  Also, in the default configuration, 
sites have the
choice of using ip_fw as a mechanism for reporting on, and/or enforcing,
their network policy.  Finally, it seems good policy for any large site 
to reduce
complexity by using the same kernel for a network boot, as is normally 
used
from disk.  Thus providing the option to remotely boot a kernel which 
now
makes sense only locally, is not as insane as it appears initially.

Each of these site policies in isolation make eminent sense. The 
questions for
you become: "Do want to provide additional support for sites who wish 
to implement
net booting as a response to end-user hardware failure, and whose 
security
policy defines the use of default deny rules for it's workstations?".

If the answer is no, then fine.  Report as much detail as you can 
before halting.
If the answer is yes, then, documenting that the "client host will 
accept
the following packets, during a network boot, until later configuration 
overrides
it.", does not seem out of line.  In either case, it makes the 
allowable policy
explicit.