From owner-freebsd-security Thu Nov 5 03:47:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA26473 for freebsd-security-outgoing; Thu, 5 Nov 1998 03:47:48 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (p30-max1.wlg.ihug.co.nz [209.78.48.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA26466 for ; Thu, 5 Nov 1998 03:47:41 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.8/8.8.7) with SMTP id AAA21220; Fri, 6 Nov 1998 00:46:52 +1300 (NZDT) (envelope-from andrew@squiz.co.nz) Date: Fri, 6 Nov 1998 00:46:52 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: Open Systems Networking cc: freebsd-security@FreeBSD.ORG Subject: Re: Amazing wonder packet Part 2. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 5 Nov 1998, Open Systems Networking wrote: > Date: Thu, 5 Nov 1998 06:24:43 -0500 (EST) > From: Open Systems Networking > To: Andrew McNaughton > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: Amazing wonder packet Part 2. > > On Fri, 6 Nov 1998, Andrew McNaughton wrote: > > > > > > > There was an earlier post that covered this which I think you haven't read > > or haven't understood. > > > > Assuming that the default policy is to deny all and assuming that rules > > are added in numerical order, the result of any rule being missing can > > only be to deny the packet, which should be safe for most purposes. > > > > In most cases there's no problem for your solution. > > No my solution is solved as robert said by just having the default policy > to deny all, and having my rules numerically ordered as they are now. > The point of my post was a solution I was mailed that implemented what > robert said in the last part to have rule one deny everything and then > remove it when the rules have loaded. This is a fix for those with a > policy of default to open in the kernel. My solution is fine since I have > deny all as my default policy and a deny all as my last rule. Which should > guarantee that my policies are carried out and that nothing sneaks by. > I was merely asking if this persons solution is what robert was thinking > for those that have a default policy of open. And if it was implemented > right. Because most people are not aware of this race condition at all. > And I plan on adding this fix to my pages for those who have a default > policy to open. So they get the same warm fuzzy feeling as I do with a > closed default policy. I just wanted to make sure that the fix I just > posted was what robert was talking about and to make sure the > solution I posted was on par with what robert said. Thats all. > I'm pretty sure it is, but wanted to double check. If you have a default to open in the kernel then what you suggest does not solve the problem. There's a window between the interface being brought up and the execution of rc.firewall which is going to be vulnerable regardless of what's in rc.firewall. If you're using ipfw as a firewall then you shouldn't be defaulting to open. Defaulting to open is appropriate if you're just using it for traffic counting, or address translation without an assumption that security is provided. root@aniwa# ipfw add 54321 deny all from any to any via ep1 ipfw: warning: interface ``ep1'' does not exist 54321 deny ip from any to any via ep1 root@aniwa# ipfw show [...] 54321 0 0 deny ip from any to any via ep1 [...] Looks like rc.firewall could be run _before_ the interfaces are set up. The warnings could be annoying though. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message