From owner-freebsd-net@FreeBSD.ORG Tue Apr 8 12:43:35 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 E28EC106566C for ; Tue, 8 Apr 2008 12:43:34 +0000 (UTC) (envelope-from yar.tikhiy@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by mx1.freebsd.org (Postfix) with ESMTP id 5B37C8FC1A for ; Tue, 8 Apr 2008 12:43:33 +0000 (UTC) (envelope-from yar.tikhiy@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so3119786fka.11 for ; Tue, 08 Apr 2008 05:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=lUX6OFZ43hB6GmxdEGxZCn/6AJG0/kZXR6JfeYaLdcc=; b=fYXI3+Lp9VpCtZRXHm1UJq+GOFfiFw77ebDJ8h1weEHsMRmgJ4T7upFQRBUoOJjldN37s6B3ztaBQhlDI+jun+GhZiUEZNlokfx7Bdlrr4H+hhKjTNDsKuBmZNPhll0wsKa9vtRzZ2tvpaJwo7VUFxva3bD8PIGm8OxnRxw+ai0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=S9lpyCn3H35t2uJgJfntvZIJ7lC/vJsfQE9T+66hyDBm2plH6FtZN0A9Sp2PgehEU2jq354WYaUhu9scwUTYjPybRnX8YJ+zQ0HDAfPmcfcq5TLi0TEImybIsmlsK2Ya80EndFepQz3s/CHQNuKs+9CCh4nINr1msP3hE6UBQrc= Received: by 10.82.118.1 with SMTP id q1mr2587048buc.62.1207658611841; Tue, 08 Apr 2008 05:43:31 -0700 (PDT) Received: by 10.82.145.1 with HTTP; Tue, 8 Apr 2008 05:43:31 -0700 (PDT) Message-ID: Date: Tue, 8 Apr 2008 16:43:31 +0400 From: "Yar Tikhiy" Sender: yar.tikhiy@gmail.com To: "Robert Watson" In-Reply-To: <20080408121535.D10870@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080407081400.GA78448@dg.local> <20080408121535.D10870@fledge.watson.org> X-Google-Sender-Auth: f7391823761e2084 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 12:43:36 -0000 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. -- Yar