On Tue, 2022-12-20 at 18:16 -0500, Steve Grubb wrote: > Hello Burn, > > On Tuesday, December 20, 2022 5:36:28 PM EST Burn Alting wrote: > > I note that the unsolicited AUDIT_BPF audit event only provides a program > > id and operation (load or unload). For example, type=BPF > > msg=audit(21/12/22 09:03:35.765:439) : prog-id=75 op=LOAD or type=BPF > > msg=audit(21/12/22 09:04:05.883:460) : prog-id=0 op=UNLOAD > > I also note that the bpf auxillary structure (struct bpf_prog_aux) that > > holds the program id value, also holds a name (struct bpf_prog_aux->name) > > and uid (struct bpf_prog_aud->user_struct->uid). Perhaps adding these two > > items to the AUDIT_BPF event would provide more security context for this > > unsolicited event. Thoughts? > > I agree that the resulting event leaves a lot to be desired. When the patch > was being merged, I think it was pointed out that all we have is a number. > The BPF folks seemed to insist that was all that was needed. They never > explained how to use that number for anything practical like knowing what was > loaded. If anything can be done to improve the situation, I'd like to > encourage a patch. Systemd triggers a bunch of these events. But what it's > doing is unknowable. > > -Steve
And to cap this off, the program id will always be zero on an UNLOAD, as the routine that sets it to zero, kernel/bpf/syscall.c:bpf_prog_free_id(), is called before the emit audit event routine, kernel/bpf/syscall.c:bpf_audit_prog(). So a bug! Rgds
-- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
