From owner-freebsd-net@FreeBSD.ORG Tue Apr 8 11:19:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26AB81065676 for ; Tue, 8 Apr 2008 11:19:08 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id EF1528FC37 for ; Tue, 8 Apr 2008 11:19:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 464BC46B4B; Tue, 8 Apr 2008 07:19:07 -0400 (EDT) Date: Tue, 8 Apr 2008 12:19:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Yar Tikhiy In-Reply-To: <20080407081400.GA78448@dg.local> Message-ID: <20080408121535.D10870@fledge.watson.org> References: <20080407081400.GA78448@dg.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, luigi@freebsd.org, oleg@freebsd.org Subject: Re: ipfw uid/gid to match listening TCP sockets? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2008 11:19:08 -0000 On Mon, 7 Apr 2008, Yar Tikhiy wrote: > Our ipfw currently doesn't seem to match this host's traffic by uid/gid if > the traffic goes to a listening TCP socket. E.g., if one tries to allow > passive data connections to a local anonymous FTP server as follows, it > won't work: > > ipfw add 10000 allow tcp from any to me dst-port 49152-65535 uid ftp in keep-state > > This behaviour is obvious from ip_fw2.c: > > 2009 if (proto == IPPROTO_TCP) { > 2010 wildcard = 0; > 2011 pi = &tcbinfo; > 2012 } else if (proto == IPPROTO_UDP) { > 2013 wildcard = INPLOOKUP_WILDCARD; > 2014 pi = &udbinfo; > 2015 } else > 2016 return 0; > > I.e., it is OK for UDP to match PCBs (essentially sockets) with a wildcard > foreign (remote) address, but not for TCP. > > I wonder if there will be any security or whatever issues if the wildcard > flag is set for TCP, too. The only peculiarity I can see now is that > listening sockets shouldn't generate outbound traffic; as soon a 3-way > handshake starts, a separate PCB is created. Thus a listening socket can > match inbound packets only. > > Are there any other points I missed? Thanks! None of this code really makes very much sense anyway, and is vulnerable to a number of races and semantic inconsistencies, not to mention application behavior that confuses it (such as sshd's opening forwarded sockets using a privileged credential). I'm not sure I agree with your analysis that listen sockets don't generate packets, btw: the syncache generates packets that are not yet from a specific socket, so arguably they are from the listen socket. All that said, I don't see any reason not to match listen sockets in the pcb lookup here. Be aware that uid/gid/jail rules may become less maintainable as our TCP locking becomes more mature. We already jump through some uncomfortable hoops to keep it working, but I'm not sure how long that can go on. Robert N M Watson Computer Laboratory University of Cambridge