From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 9 08:34:14 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD8DF1065678 for ; Tue, 9 Sep 2008 08:34:14 +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 A39B38FC1B for ; Tue, 9 Sep 2008 08:34:14 +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 7F55146BAD; Tue, 9 Sep 2008 04:34:12 -0400 (EDT) Date: Tue, 9 Sep 2008 09:34:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daan Vreeken In-Reply-To: <200809090223.46472.Daan@vehosting.nl> Message-ID: References: <20080908185106.GB6629@dan.emsphone.com> <200809090223.46472.Daan@vehosting.nl> User-Agent: Alpine 1.10 (BSF 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, "Dan Mahoney, System Admin" , Dan Nelson Subject: Re: IPFW uid logging... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2008 08:34:14 -0000 On Tue, 9 Sep 2008, Daan Vreeken wrote: >>>> Which is to say, they don't include the UID -- and I have several hundred >>>> sites, each with its own UID. >>>> >>>> Yes, I could go ahead and set up a thousand "deny" rules, one for each >>>> UID -- but being able to log this info (since it IS being checked) would >>>> be great. >>> >>> It should be possible to add a couple more arguments to ipfw_log() so that >>> ipfw_chk() can pass it the ugid_lookup flag and a pointer to the >>> fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of >>> that struct if ugid_lookup==1. That would result in the logging of uid >>> for any failed packet that had to go through a uid check on the way to the >>> deny rule. >> >> Okay, so if it's fairly easy to do, the question would be "since I don't >> feel right hacking in this change myself -- how could I propose this as a >> feature?" It's not a BUG per-se, but I think it could be useful to others >> as well. > > I own a webhosting company and here too every domain gets it's own user, so > I like this proposal. I've hacked together a first try, which seems to be > working. A patch (against -HEAD) can be found here : > > http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff > > Improvements / tips / comments are welcome ;-) A few observations generally about the use of connection credential data in the firewall: (1) UID lookups on connections from the firewall are inherently race-prone and unreliable; the stack layering violation means that locks may be acquired independently for the connection lookup at the firewall and socket layers. This non-atomicity may be fairly acceptable in the event that there aren't significant delays in processing, but if you also have DUMMYNET pipes in use then these races may mean significant gaps in time between when a socket is looked up for check vs. use. (2) The performance hit of connection lookups in order to find credentials for received packets may (should) be massive: the input path will look up the connection for each packet multiple times, acquiring contended locks, etc. (3) It's currently not possible to look up the connection associated with several sorts of packets, including ICMP (such as used with PMTU). Note that all of these problems apply to existing uid/gid/jail credential rules, which are considered unreliable and non-performant for the same reasons. Looking at your patch specifically, it seems you don't force the lookup of credential information if it hasn't already being looked up for a credential rule. This should mean that the known problems of (1), (2), and (3) shouldn't be worse than they were before. Robert N M Watson Computer Laboratory University of Cambridge