IPFW uid logging...

[Robert Watson]

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