Date: Tue, 9 Sep 2008 09:34:13 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Daan Vreeken <Daan@vehosting.nl> Cc: freebsd-hackers@freebsd.org, "Dan Mahoney, System Admin" <danm@prime.gushi.org>, Dan Nelson <dnelson@allantgroup.com> Subject: Re: IPFW uid logging... Message-ID: <alpine.BSF.1.10.0809090925500.66707@fledge.watson.org> In-Reply-To: <200809090223.46472.Daan@vehosting.nl> References: <alpine.BSF.2.00.0809081110480.63702@prime.gushi.org> <20080908185106.GB6629@dan.emsphone.com> <alpine.BSF.2.00.0809081559490.71254@prime.gushi.org> <200809090223.46472.Daan@vehosting.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.1.10.0809090925500.66707>