On Wed, 2022-12-21 at 09:54 -0500, Paul Moore wrote: > On Wed, Dec 21, 2022 at 9:44 AM Paul Moore <p...@paul-moore.com> wrote: > > On Tue, Dec 20, 2022 at 7:02 PM Burn Alting <burn.alt...@iinet.net.au> > > wrote: > > > And to cap this off, the program id will always be zero on an UNLOAD, > > > asthe > > > 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! > > > > Ooof :/ Independent of the other issues this is something we shouldfix as > > soon > > as we can. I'll take a look during the holiday and seewhat we can do to fix > > this; looking quickly at it now I don't think itwill be too bad, but one > > never > > knows for sure ... > > I'm still just looking at the code, but I think we can also do abetter job > associating eBPF UNLOAD operations As Steve suggests, it would have value to provide more information (name, tag, uid) and I don't know if it's possible but relate it to the bpf syscall's file descriptor for the map created or program loaded (the exit value).
-- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
