BUG: Incorrect proctitle in audit events #170
Description
I opened a similar bug in the systemd project, but they sent me to the audit team.
Sometimes audit logs contain entries with suspicious process names (proctitle). These names are the endings of process names taken from the end of the process name:
type=PROCTITLE msg=audit(04.06.2025 12:43:48.432:2105) : proctitle=(kManager)
type=SYSCALL msg=audit(04.06.2025 12:43:48.432:2105) : arch=x86_64 syscall=fstat success=yes exit=0 a0=0xf a1=0x7ffe5330cc20 a2=0x7ffe5330cc20 a3=0x0 items=0 ppid=1 pid=408 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=NetworkManager exe=/usr/sbin/NetworkManager subj=0:63:0:0:0 key=(null)
type=PATH msg=audit(04.06.2025 12:43:48.432:2105) : /class/net/lo->../../devices/virtual/net/lo
type=PROCTITLE msg=audit(04.06.2025 12:43:49.040:3627) : proctitle=(ostnamed)
type=SYSCALL msg=audit(04.06.2025 12:43:49.040:3627) : arch=x86_64 syscall=fstat success=yes exit=0 a0=0x9 a1=0x7ffde1e37d40 a2=0x7ffde1e37d40 a3=0x0 items=0 ppid=1 pid=589 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-hostnam exe=/usr/lib/systemd/systemd-hostnamed subj=0:63:0:0:0 key=(null)
type=PATH msg=audit(04.06.2025 12:43:49.040:3627) : /etc/os-release->/usr/lib/os-release
In the process of investigating the problem, debugging was added to the kernel using a trivial printk output. I was interested in the sections of code responsible for manipulating the task name field (structure 'task_struct', field 'comm').
The following debug output was obtained from the Linux kernel, illustrating the problem:
[ 5805.995533] prctl: P=6027 comm=(yslog-ng)
[ 5805.995542] SETTASKCOM: P=6027 B=(yslog-ng) C=(yslog-ng)
[ 5806.017771] do_execveat_common: fn=/usr/sbin/syslog-ng
[ 5806.018506] SETTASKCOM: P=6027 B=syslog-ng C=syslog-ng
[ 5806.018513] SETTASKCOM F: P=6027 /usr/sbin/syslog-ng'
As can be seen from the logs, the prctl system call is executed (the command PR_SET_NAME) to set the process name. It uses the __set_task_comm function to set the process name.
After which, some time later, inside the do_execveat_common function, the __set_task_comm function is also called to set the process name, but with the name taken from the file path.
If something happens between these two events that causes the system call to be audited, the audit context will "snap" the original process name (in parentheses) and "remember" it. This name will not change after that.
I analyzed systemd:
strace -f -e prctl -p 1
And I found that systemd is actually setting process names when it starts, for example:
[pid 6306] prctl(PR_SET_NAME, "(yslog-ng)") = 0
Then I found the supposed place where the process name is set
So the situation is as follows:
systemd sets a name in a certain format when it starts a process. Then, when the process executes the exec system call, this name is replaced with the name from the file path (maybe I expressed myself incorrectly, but this does not affect the essence of the problem). There is a window between these events, in which auditctx can "capture" the first set process name and will not change it anymore.
It turns out that sometimes the audit context can capture the "intermediate" name of the process (when systemd has already forked, but has not executed exec) and this name will not change further. I assume that when changing the name in do_execveat_common, it is necessary to change the name of the process in the audit context (struct audit_context, field proctitle). Otherwise, a situation arises that if in the "intermediate" time (between fork and exec) the process executed a system call subject to audit, then this name is "latched" (although this name is temporary, as the systemd community indicated in the bug report) only once here and does not change anymore.
Also, the systemd command pointed out potential problems with the process name, since this name is under the user's control (modifiable by the same systemd at startup). And at any time, the process can change its name as prctl(PR_SET_NAME, ...).
Some security is provided by the fact that this name is "latched" in the audit context once and does not change anymore. But this is also the reason for my bug report.