Bug 122773 - [pf] pf doesn't log uid or pid when configured to
Summary: [pf] pf doesn't log uid or pid when configured to
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 7.0-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-pf mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-14 23:10 UTC by Josh
Modified: 2020-01-16 21:54 UTC (History)
3 users (show)

See Also:


Attachments
tcpdump-uid.diff (683 bytes, patch)
2008-04-15 02:01 UTC, Max Laier
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Josh 2008-04-14 23:10:02 UTC
When pf is configured to log the UID and PID of the process sending
traffic, it doesn't.

How-To-Repeat: Configure pf with a rule such as:

pass out log (user) quick on $exif inet proto tcp from $exif to any keep state

Start pflog (/etc/rc.d/pflog + rcvar), then run "tcpdump -netttvvvi
pflog0", which is supposed to display the info. You should get something
like (from google):

rule 10/(match) [uid 0, pid 1807] block in on fxp0: 85.100.124.74.14464 \
server1.443: [|tcp] (ttl 249, id 65259, len 40, bad cksum 0! differs by f890)

But I actually get something like:

044014 rule 17/0(match): pass out on bge0: (tos 0x10, ttl 64, id 11138, \
offset 0, flags [DF], proto TCP (6), length 60) 64.132.211.219.57274 > \
66.94.234.13.80: [|tcp]

Other users on #freebsd@freenode reported the same behavior.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2008-04-15 00:51:36 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-pf

Over to maintainer(s).
Comment 2 Max Laier 2008-04-15 02:01:18 UTC
The problem is twofold: 
 1) FreeBSD doesn't store the PID for the opening process in the socket 
    credentials.
 2) tcpdump currently doesn't report uid/pid at all.

The first issue could probably be fixed, but would touch quite a lot of 
things - it's really an industrious task.  Feel free to submit patches ;)  
I don't currently have the time to do this.

The second issue can be addressed with the attached patch, which should 
enable you to display the UID.  It will report NO_PID (100000) for 
everything as long as 1 isn't fixed, though.

-- 
Max
Comment 3 olivier 2013-07-01 13:42:41 UTC
Hi,
I've got the same problem on 9-stable too.

pflogd didn't add the good UID value on its pcap.

Here is a pflogd packet displayed on wireshark (my user had UID 1001
for this test):

No.     Time        Source                Destination
Protocol Length Info
      1 0.000000    10.2.1.3              10.2.0.67             TCP
  124    [pass em0/0] 32186 > ssh [SYN] Seq=0 Win=65535 Len=0 MSS=1460
WS=64 SACK_PERM=1 TSval=615127099 TSecr=0

Frame 1: 124 bytes on wire (992 bits), 124 bytes captured (992 bits)
PF Log IPv4 pass on em0 by rule 0
    Header Length: 61
    Address Family: IPv4 (2)
    Action: pass (0)
    Reason: match (0)
    Interface: em0
    Ruleset:
    Rule Number: 2
    Sub Rule Number: 16777216
    UID: -385679360
    PID: -1601830656
    Rule UID: 0
    Rule PID: -1990852608
    Direction: out (2)
    Padding: 000000
Internet Protocol Version 4, Src: 10.2.1.3 (10.2.1.3), Dst: 10.2.0.67
(10.2.0.67)
Transmission Control Protocol, Src Port: 32186 (32186), Dst Port: ssh
(22), Seq: 0, Len: 0
    Source port: 32186 (32186)
    Destination port: ssh (22)
    [Stream index: 0]
    Sequence number: 0    (relative sequence number)
    Header length: 40 bytes
    Flags: 0x002 (SYN)
    Window size value: 65535
    [Calculated window size: 65535]
    Checksum: 0xe2c8 [validation disabled]
    Options: (20 bytes), Maximum segment size, No-Operation (NOP),
Window scale, SACK permitted, Timestamps

Regards,

Olivier
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:45:59 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 5 Kristof Provost freebsd_committer 2018-10-19 20:56:11 UTC
It looks like the kernel side of this (at least for uid) is present.
I've updated the patch:

diff --git a/contrib/tcpdump/print-pflog.c b/contrib/tcpdump/print-pflog.c
index 265efd3c866..38201c55ee3 100644
--- a/contrib/tcpdump/print-pflog.c
+++ b/contrib/tcpdump/print-pflog.c
@@ -97,8 +97,12 @@ pflog_print(netdissect_options *ndo, const struct pfloghdr *hdr)
        else
                ND_PRINT((ndo, "rule %u.%s.%u/", rulenr, hdr->ruleset, subrulenr));

-       ND_PRINT((ndo, "%s: %s %s on %s: ",
-           tok2str(pf_reasons, "unkn(%u)", hdr->reason),
+       ND_PRINT((ndo, "%s", tok2str(pf_reasons, "unkn(%u)", hdr->reason)));
+
+       if (hdr->uid != UID_MAX)
+               ND_PRINT((ndo, " [uid %u]", (unsigned)hdr->uid));
+
+       ND_PRINT((ndo, ": %s %s on %s: ",
            tok2str(pf_actions, "unkn(%u)", hdr->action),
            tok2str(pf_directions, "unkn(%u)", hdr->dir),
            hdr->ifname));

A simple ping now produces this:
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes
 00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 20885, offset 0, flags [none], proto UDP (17), length 55)
    172.16.2.2.64345 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x964f!] 27130+ A? google.be. (27)
 00:00:00.071014 rule 0/0(match) [uid 0]: pass out on vtnet0: (tos 0x0, ttl 64, id 63862, offset 0, flags [none], proto ICMP (1), length 84)
    172.16.2.2 > 172.217.18.163: ICMP echo request, id 35102, seq 0, length 64

If anyone is still interested in this, can you test it and let me know if this works for you?
Comment 6 Kristof Provost freebsd_committer 2018-10-20 18:32:22 UTC
Review in https://reviews.freebsd.org/D17625
Comment 7 commit-hook freebsd_committer 2018-10-21 21:18:42 UTC
A commit references this bug:

Author: kp
Date: Sun Oct 21 21:17:43 UTC 2018
New revision: 339557
URL: https://svnweb.freebsd.org/changeset/base/339557

Log:
  tcpdump: Log uid on pflog interfaces

  If pf logs the user id ('pass out log (user)') have tcpdump also print
  this.

  Example output:
   00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 57539, offset 0, flags [none], proto UDP (17), length 55)
      172.16.2.2.18337 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x16e4!] 40222+ A? google.be. (27)

  PR:		122773
  Differential Revision:	https://reviews.freebsd.org/D17625

Changes:
  head/contrib/tcpdump/print-pflog.c
Comment 8 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-19 19:39:37 UTC
There was a commit referencing this bug, but it's still not closed and has been inactive for some time. Closing as "fixed". Please re-open it if the issue hasn't been completely resolved.
Comment 9 Kristof Provost freebsd_committer 2019-01-19 21:15:20 UTC
Note that while we do log the uid we don’t log the pid. Offhand I think that that was a nontrivial bit of extra work. 

I have no immediate plans to implement that, so I’m okay with keeping this closed.
Comment 10 ferdinand.goldmann 2020-01-16 13:51:32 UTC
This still does not seem to work.

I have the following rule in my pf.conf:
block out log (user) quick on $pub_if all user { >= 1001 }

However, when I log blocked connections, I cannot see the UID in the logged messages (IP addresses X'ed out):

# tcpdump -i pflog0 -n -p -e -tttt -vv action block
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes
2020-01-16 14:47:23.314075 rule 1/0(match): block out on bge0: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    X.X.X.33.47508 > X.X.X.65.25: Flags [S], cksum 0x212d (incorrect -> 0xdb8e), seq 631109046, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 1497242932 ecr 0], length 0

I'm running a current version of FreeBSD:
freebsd-version -kru
11.3-RELEASE-p5
11.3-RELEASE-p5
11.3-RELEASE-p5

I have tried various different invocations of tcpdump and even tcpdump from the ports to no avail. When I look at the packets in wireshark, I see that either negative or very high values are logged for both UID and PID. Any ideas? Shouldn't it print at least the UID by now?
Comment 11 commit-hook freebsd_committer 2020-01-16 21:54:03 UTC
A commit references this bug:

Author: kp
Date: Thu Jan 16 21:53:36 UTC 2020
New revision: 356814
URL: https://svnweb.freebsd.org/changeset/base/356814

Log:
  MFC r339557:

  tcpdump: Log uid on pflog interfaces

  If pf logs the user id ('pass out log (user)') have tcpdump also print
  this.

  Example output:
   00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 57539, offset 0, flags [none], proto UDP (17), length 55)
      172.16.2.2.18337 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x16e4!] 40222+ A? google.be. (27)

  PR:		122773

Changes:
_U  stable/12/
  stable/12/contrib/tcpdump/print-pflog.c
Comment 12 commit-hook freebsd_committer 2020-01-16 21:54:05 UTC
A commit references this bug:

Author: kp
Date: Thu Jan 16 21:53:38 UTC 2020
New revision: 356815
URL: https://svnweb.freebsd.org/changeset/base/356815

Log:
  MFC r339557:

  tcpdump: Log uid on pflog interfaces

  If pf logs the user id ('pass out log (user)') have tcpdump also print
  this.

  Example output:
   00:00:00.000000 rule 0/0(match) [uid 1001]: pass out on vtnet0: (tos 0x0, ttl 64, id 57539, offset 0, flags [none], proto UDP (17), length 55)
      172.16.2.2.18337 > 172.16.2.1.53: [bad udp cksum 0x5c58 -> 0x16e4!] 40222+ A? google.be. (27)

  PR:		122773

Changes:
_U  stable/11/
  stable/11/contrib/tcpdump/print-pflog.c
Comment 13 Kristof Provost freebsd_committer 2020-01-16 21:54:40 UTC
(In reply to ferdinand.goldmann from comment #10)
That's because this fix was never MFCd back to stable/11 or stable/12. It's fixed in head, but only there.

I've now done the MFC, so it should at least be fixed in the next 11 and 12 released.