ipfw - default to accept + bootp = confusion.
Juli Mallett
jmallett at FreeBSD.org
Wed Aug 6 23:23:15 PDT 2003
* 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
> 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 at freebsd.org; efnet: juli; aim: bsdflata;
i have lost my way home early - i don't care cause i won't stay there.
More information about the freebsd-current
mailing list