From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 23:15:35 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAE3437B401 for ; Wed, 6 Aug 2003 23:15:35 -0700 (PDT) Received: from papoose.quick.com (papoose.quick.com [199.120.187.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF61F43FA3 for ; Wed, 6 Aug 2003 23:15:34 -0700 (PDT) (envelope-from jq@quick.com) Received: from quick.com (lili.chezq.com [199.120.187.254]) by papoose.quick.com (8.12.9/8.12.9) with ESMTP id h776FXBB020196; Thu, 7 Aug 2003 02:15:33 -0400 (EDT) (envelope-from jq@quick.com) Date: Thu, 7 Aug 2003 02:15:26 -0400 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: Juli Mallett From: James Quick In-Reply-To: <1060230124.65628.15.camel@sprout> Message-Id: <891767A2-C89E-11D7-8364-003065C496DC@quick.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: freebsd-current@freebsd.org Subject: Re: ipfw - default to accept + bootp = confusion. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2003 06:15:36 -0000 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.)