IPFW uid logging...
rwatson at FreeBSD.org
Tue Sep 9 08:34:14 UTC 2008
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 :
> Improvements / tips / comments are welcome ;-)
A few observations generally about the use of connection credential data in
(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
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
University of Cambridge
More information about the freebsd-hackers