From owner-freebsd-net@FreeBSD.ORG Tue Apr 8 17:29:05 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 F1FC71065672 for ; Tue, 8 Apr 2008 17:29:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outF.internet-mail-service.net (outf.internet-mail-service.net [216.240.47.229]) by mx1.freebsd.org (Postfix) with ESMTP id D763C8FC15 for ; Tue, 8 Apr 2008 17:29:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 08 Apr 2008 15:46:02 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 6D4E42D70F0; Tue, 8 Apr 2008 10:29:01 -0700 (PDT) Message-ID: <47FBAB61.2050604@elischer.org> Date: Tue, 08 Apr 2008 10:29:05 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Yar Tikhiy References: <20080407081400.GA78448@dg.local> <20080408121535.D10870@fledge.watson.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, luigi@freebsd.org, oleg@freebsd.org, Robert Watson 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 17:29:06 -0000 Yar Tikhiy wrote: > On Tue, Apr 8, 2008 at 3:19 PM, Robert Watson wrote: >> >> 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. > > Thank you for these points! Matching packets from listen sockets makes > the case even simpler; then it's the matter of changing the "wildcard = 0;" > to "wildcard = INPLOOKUP_WILDCARD;". At least matching listen sockets > doesn't seem to break things not already broken. > >> 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. > > I've always viewed uid/gid rules as a hack that works for now. In the long run > we may want to consider an API allowing privileged apps to punch holes > in the firewall in a controllable manner. Of course, the API should be agnostic > of the particular firewall type. Then, e.g., ftpd(8) would be able to > open its current > passive data port only and to a single remote IP, and the whole port > range wouldn't > need to be exposed. Such holes could be handled as dynamic rules/states so that > they don't stay there forever if the app crashes. we use these rules in a totally different manner... i.e. so one 'replacement' may not suit all users.. only people that use it in that manner. how we use it: transparent redirection for a proxy, where the proxy is pretending to be the client.... fwd 127.0.0.1:80 tcp from any 80 to any in recv ${outside_iface} uid ${proxy_uid} If the proxy has a socket that matches the packet it gets captured, even if there is no other reason tho think it would be local.. >