Date: Thu, 7 Aug 2003 01:23:14 -0500 From: Juli Mallett <jmallett@FreeBSD.org> To: James Quick <jq@quick.com> Cc: Juli Mallett <jmallett@landmarknetworks.com> Subject: Re: ipfw - default to accept + bootp = confusion. Message-ID: <20030807012314.A64518@FreeBSD.org> In-Reply-To: <891767A2-C89E-11D7-8364-003065C496DC@quick.com>; from jq@quick.com on Thu, Aug 07, 2003 at 02:15:26AM -0400 References: <1060230124.65628.15.camel@sprout> <891767A2-C89E-11D7-8364-003065C496DC@quick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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 > making assumptions about trust on behalf of the user. On the other > hand, we just accepted a kernel from someone, and now want > to get some data for a root partition, so if we cannot trust the host > we're > booting from, what's the point? > > Given the above, would it be possible, to embed a small function > taking just a pair of addresses and masks, and use that to add a rule > so that > this process could continue? After using sysctl to verify the > predicament, > you could then try installing one (or a few) rules to trust the machines > that are booting us. Trust the server running bootpd, trust the dchp > and > nfs server, or just trust the network+submask in a single rule. > > the following is just a rough guess from looking at ip_fw.c. > I don't know how far off it is to being valid. > > s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); > if (s < 0) > err(EX_UNAVAILABLE, "socket"); > memset(&rule, 0, sizeof rule); > rule.fw_flg |= IP_FW_F_ACCEPT; > rule.fw_prot = IPPROTO_IP; > rule.fw_src = /* the bootp servers address > rule.fw_smsk = ~0; /* Does all 1s mean just from that host? */ > rule.fw_dst = /* Is our addr known yet? */ > rule.fw_dmsk = ??; > rule.fw_flg |= (IP_FW_F_OUT|IP_FW_F_IN); /* you could do both > directions */ > i = sizeof(rule); > if (getsockopt(s, IPPROTO_IP, IP_FW_ADD, &rule, &i) == -1) > err(EX_UNAVAILABLE, "getsockopt(%s)", "IP_FW_ADD"); > > Is any of this reasonable or I am just being naive? (I'm new here.) 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. -- juli mallett. email: jmallett@freebsd.org; efnet: juli; aim: bsdflata; i have lost my way home early - i don't care cause i won't stay there.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030807012314.A64518>