On Thursday, August 7, 2003, at 02:23 AM, Juli Mallett wrote:
* James Quick <[EMAIL PROTECTED]> [ 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.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
