Date: Thu, 5 Nov 1998 10:42:10 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-security@FreeBSD.ORG Subject: Re: Amazing wonder packet Part 2. Message-ID: <Pine.BSF.3.96.981105103648.5251A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.3.96.981105082421.4653A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
So in case anyone missed it in the verbosity of my previous email, I described a race condition involving rc.pccard and dhcp where network programs are executed prior to the installation of firewall rules (possibly leading to applications being exposed to the network where the ipfw rules in rc.firewall should not allow it). I also described a situation where, if your pccard script executed ipfw commands (seems reasonable for a card insert or remove), then you could get unexpected results due to interlacing of rc.firewall and pccard.conf ipfw commands. The program execution problem appears to exist only when the default policy is 'accept'. The pccard.conf ipfw problem exists even when the default policy is 'deny', I believe. I also raised the question: are packets ever queued after acceptance by ipfw such that they could be received later if the port is not yet bound? For example, suppose ipfw in a nascent or under-developed state accepts a packet, and then later named is started -- is it possible through any race conditions that the packet accepted earlier will make it to named later? Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981105103648.5251A-100000>