> On 15 Dec 2023, at 22:20, Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote:
>
> On 12/15/23 6:46 PM, Dave Tucker wrote:
>> Current output from auditd is as follows:
>> time->Wed Dec 13 21:39:24 2023
>> type=BPF msg=audit(1702503564.519:11241): prog-id=439 op=LOAD
>> This only tells you that a BPF program was loaded, but without
>> any context. If we include the prog-name, pid, uid and comm we get
>> output as follows:
>> time->Wed Dec 13 21:59:59 2023
>> type=BPF msg=audit(1702504799.156:99528): op=UNLOAD prog-id=50092
>> prog-name="test" pid=27279 uid=0 comm="new_name"
>> With pid, uid a system administrator has much better context
>> over which processes and user loaded which eBPF programs.
>> comm is useful since processes may be short-lived.
>> Signed-off-by: Dave Tucker <dave@xxxxxxxxxxxxx>
>> ---
>> Changes:
>> v2->v3:
>> - Revert replacing in_irq() with in_hardirq()
>> - Revert removal of in_irq() check from bpf_audit_prog since it may
>> also be called in the sofirq or nmi contexts
>> v1->v2:
>> - Move 'op' to the front of the audit messages
>> - Add 'prog-name' to the audit messages
>> - Replace deprecated in_irq() with in_hardirq()
>> - Remove in_irq() check from bpf_audit_prog since it's always called
>> from the task context
>> - Only populate pid, uid and comm if not in a kthread
>
> Aside from what Alexei mentioned, looking back at commit bae141f54be83
> ("bpf: Emit audit messages upon successful prog load and unload"), don't
> you already have this information at hand? Quote from commit msg:
>
> Raw example output:
>
> # auditctl -D
> # auditctl -a always,exit -F arch=x86_64 -S bpf
> # ausearch --start recent -m 1334
> ...
> ----
> time->Wed Nov 27 16:04:13 2019
> type=PROCTITLE msg=audit(1574867053.120:84664): proctitle="./bpf"
> type=SYSCALL msg=audit(1574867053.120:84664): arch=c000003e syscall=321 \
> success=yes exit=3 a0=5 a1=7ffea484fbe0 a2=70 a3=0 items=0 ppid=7477 \
> pid=12698 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 \
> egid=1001 sgid=1001 fsgid=1001 tty=pts2 ses=4 comm="bpf" \
> exe="/home/jolsa/auditd/audit-testsuite/tests/bpf/bpf" \
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
> type=UNKNOWN[1334] msg=audit(1574867053.120:84664): prog-id=76 op=LOAD
> ----
> time->Wed Nov 27 16:04:13 2019
> type=UNKNOWN[1334] msg=audit(1574867053.120:84665): prog-id=76 op=UNLOAD
> ...
The information is only there if you’ve added an audit rule like the one above
to capture the bpf syscall. With the default rules of `auditctl -a task,never`
(at least that’s the default on my system) all you see is:
---
time->Mon Dec 18 13:51:47 2023
type=BPF msg=audit(1702907507.727:858492): prog-id=965 op=LOAD
----
time->Mon Dec 18 13:51:49 2023
type=BPF msg=audit(1702907509.031:858493): prog-id=965 op=UNLOAD
——
I’d be okay with adding rules to enrich the context if it was possible to
constrain auditing to only certain bpf_cmds, but I’ve not been successful so
far. The rule `always, exit -F arch=b64 -S bpf -F a0=5` still shows map ops in
the audit logs. On a busy system that floods the audit log with noise and useful
logs can be lost due to log rotation.
- Dave
> Thanks,
> Daniel
