p 103 of "Linux Firewalls" 2nd Ed by Robert Ziegler discusses the 'owner match extension' that matches the packet's creator.
A match can occur on uid, gid, pid, or sid. The extension can be used on the OUTPUT chain only.
On 2009-02-11 19:46, Dan Martin wrote:
p 103 of "Linux Firewalls" 2nd Ed by Robert Ziegler discusses the 'owner match extension' that matches the packet's creator.
A match can occur on uid, gid, pid, or sid. The extension can be used on the OUTPUT chain only.
And right in the iptables(1) man page...
owner This module attempts to match various characteristics of the packet creator, for locally-generated packets. It is only valid in the OUTPUT chain, and even this some packets (such as ICMP ping responses) may have no owner, and hence never match.
--uid-owner userid Matches if the packet was created by a process with the given effective user id.
--gid-owner groupid Matches if the packet was created by a process with the given effective group id.
--pid-owner processid Matches if the packet was created by a process with the given process id.
--sid-owner sessionid Matches if the packet was created by a process in the given ses- sion group.
--cmd-owner name Matches if the packet was created by a process with the given command name. (this option is present only if iptables was com- piled under a kernel supporting this feature)
NOTE: pid, sid and command matching are broken on SMP
So, apparently, you can even match based on the command name. Note, however, the very last line about SMP... With multi-core CPU's becoming the norm, that means it's pretty much broken for any new hardware.
Of course, there is always a simple work-around: run the daemons you want to track this way each with their own uid and/or gid. (Red Hat systems mostly do this already these days, at least for most network services, to avoid collateral damage if a particular daemon is vulnerable.)