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

* 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.