Date: Thu, 7 Aug 2003 12:52:48 -0400 From: James Quick <jq@quick.com> To: Juli Mallett <jmallett@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG Subject: Re: ipfw - default to accept + bootp = confusion. Message-ID: <93909532-C8F7-11D7-8364-003065C496DC@quick.com> In-Reply-To: <20030807012314.A64518@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, August 7, 2003, at 02:23 AM, Juli Mallett wrote: > * James Quick <jq@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93909532-C8F7-11D7-8364-003065C496DC>