BPF audit logs

[Burn Alting]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20221221/701e43d8/attachment-0001.htm>