Bug Description

The kernel / netfilter is lacking the the ability to identify the local origin of network conection. (see comments)

This lack was first reported against loging facilities, but tracked down to kernel disability.

Please foreward / reassign to handle this as appropriate.

original post:
---
The gnome "Log File Viewer" does not log the Process Name (or Application Name) that generated the log item. For example, if an outbound internet connection is blocked and this event is logged, only the "ID" (i.e., PID) is shown in the report. But the PID is useless because it is ephemeral and does not live past the session. Users are left with no way to learn what Application or Process was responsible for generating the log item.

It isn't the syslogd's responsibility to do a lookup of the pid, it is the application and the application is the one specifying the pid anyway.

Based on the example given, it sounds like what is desired is for the firewall to log the pid of the application that generated the request. This is the kernel's responsibility via netfilter, and netfilter is controlled via iptables (and up above maybe another tool like ufw). However, iptables does not support this (see 'man iptables' for more information). It used to have the '--cmd-owner' option, but this was removed long ago because it was deemed unfixably broken.

@Jamie Strandboge, is there anything that can be done to get this capability in Ubuntu? Perhaps some other solution can be created or put on the planning board? A lot of people want to have a log of the outgoing internet connections of applications. Unless users are willing to sit and stare at the monitor while connections occur every second they are on their computer, users have no way of learning what apps are making outgoing connections on their computers. There's got to be some way give Ubuntu users this capability.

The capability to log "process names" has been requested by numerous users over the years, here's some links:

nethogs and netstat can connect pids to program names, so in theory someone could add this functionality to iptables. You could also setup a cron job to regularly log netstat output for all network connections to a file. For example, the following command ran as root will timestamp and log all network connections every 5 seconds to log.txt:
# while [ 1 == 1 ]; do date >> log.txt; netstat -pn -A inet --wide >> log.txt; sleep 5 ; done
You can run without root privledge, however process you don't own won't be included. Hope this helps a little.

What Robbie suggests could kinda work, but because it is polling a snapshot in time, it is not really a satisfactory solution for people wanting to continually map outgoing connections to a program name. The superuser.com site has tips on how to write a program that could poll various things in /proc, but this is not this bug. This bug is asking for logging the process name for network packets (the PID could in theory satisfy this, but there is still the problem of the polling interval).

Most of the desire surrounding this sort of logging has to do with application firewalls where you have specific firewall rules based on the application producing the network traffic. There used to be a --cmd-owner option for iptables that would configure the firewall to more of less do what you wanted but the kernel as of 2.6.14 stopped supporting this. The Debian bug report referring to the removal of --cmd-owner is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492284

Rip out cmd/sid/pid matching since its unfixable broken and stands in the
way of locking changes to tasklist_lock."

LSMs such as AppArmor could be used to help with application firewalls, but at this time AppArmor network mediation is very coarse-grained. Support is planned for better network mediation-- the first cut will allow specifying network rules by port. After that we would tie in with secmark which will allow us to filter based on the contents of the secmark. Both of these would improve the situation for application firewalls to varying degrees, and a creative complain-mode global AppArmor policy could in theory be used to show which applications are making the outgoing connections.