Re: [RFC] audit support for BPF notification

[Jiri Olsa <jolsa@redhat.com>]

hi,
Adding Vlad Dronov to the loop, because he asked
about this functionality some time ago.

Vlad, the full thread can be found in here:
  https://www.redhat.com/archives/linux-audit/2019-August/msg00004.html

Any thoughts on this?

thanks,
jirka

On Mon, Aug 12, 2019 at 04:33:10PM +0200, Jiri Olsa wrote:
> On Mon, Aug 12, 2019 at 09:49:43AM -0400, Steve Grubb wrote:
> > On Monday, August 12, 2019 3:59:22 AM EDT Jiri Olsa wrote:
> > > On Fri, Aug 09, 2019 at 01:45:21PM -0400, Steve Grubb wrote:
> > > > Hello,
> > > > 
> > > > On Friday, August 9, 2019 10:18:31 AM EDT Jiri Olsa wrote:
> > > > > I posted initial change that allows auditd to log BPF program
> > > > > 
> > > > > load/unload events, it's in here:
> > > > >   https://github.com/linux-audit/audit-userspace/pull/104
> > > > 
> > > > Thanks for the patch...but we probably should have talked a bit more
> > > > before undertaking this effort. We normally do not audit from user space
> > > > what happens in the kernel. Doing this can be racy and it keeps auditd
> > > > from doing the one job it has - which is to grab events and record them
> > > > to disk and send them out the realtime interface.
> > > > 
> > > > > We tried to push pure AUDIT interface for BPF program notification,
> > > > > 
> > > > > but it was denied, the discussion is in here:
> > > > >   https://marc.info/?t=153866123200003&r=1&w=2
> > > > 
> > > > Hmm. The email I remember was here:
> > > > https://www.redhat.com/archives/linux-audit/2018-October/msg00053.html
> > > > 
> > > > and was only 2 emails long with no answer to my question. :-)
> > > 
> > > oops, sry about that, your question was:
> > > 	> I'm not sure exactly what the issue is. You can audit for specific
> > > 	> syscall
> > > 	> and argument. So, if you want to see loads, then you can make a rule
> > > 	> like:
> > > 	> 
> > > 	> -a always,exit -F arch=b64 -S bpf -F a0=5
> > > 
> > > The problem with above for us is that we also:
> > > 
> > >   - need to log also other properties of the BPF program,
> > >     which are not visible from BPF syscall arguments, like
> > >     its ID, JIT status 
> > 
> > The way this is normally done is to add a supplemental record. For example, 
> > when auditing the open syscall, we also get CWD & PATH supplemental records. 
> > When auditing connect, we get a SOCKADDR supplemental record. We have 
> > requirements around selective audit whereby the admin is in control of what 
> > is selected for audit via audit rules. So, what one could do is set a rule 
> > for the bpf syscall and then when it triggers, we get these other records 
> > added to the bpf syscall event.
> 
> right, that was the initial plan, but BPF guys wanted just
> single notification system without specific hooks for audit,
> so we ended up with perf specific interface
> 
> > >     or license info
> > 
> > This ^^ is not a security issue.
> > 
> > 
> > >   - need to see BPF program UNLOAD, which is not done
> > >     via syscall, so those would be unvisible at all
> > 
> > Is there a place in the kernel where this happens? I could see abnormal 
> > termination being something we might want. Does the program go through 
> > something like an exit syscall internally?
> 
> it's happening in here (kernel/bpf/syscall.c):
> 
> 	bpf_prog_put
> 	  __bpf_prog_put
> 	  {
> 		    if (atomic_dec_and_test(&prog->aux->refcnt)) {
> 			perf_event_bpf_event(prog, PERF_BPF_EVENT_PROG_UNLOAD, 0);
> 			...
> 	  }
> 
> BPF program is released when it drops the reference count,
> which is normally when its file descriptor is closed.
> 
> However it might get pinned and stay alive even when the initial
> file descriptor is closed.. and then there's the networking world,
> which might have some other specific ways.. but it all ends up
> in bpf_prog_put and zero reference count.
> 
> > > > > The outcome of the discussion was to use perf event interface
> > > > > for BPF notification and use it in some deamon.. audit was our
> > > > > first choice.
> > > > > 
> > > > > thoughts?
> > > > 
> > > > I'd like to understand what the basic problem is that needs to be solved.
> > > 
> > > we need a way for administrators to see the history of loaded BPF
> > > programs, to help investigating issues related to BPF.. and the
> > > only BPF interface for this data is through perf ring buffer
> > 
> > That is really not the audit way. Let's keep talking to see where this ends 
> > up.
> 
> Would you see some other auditing daemon/app in place for this kind of data?
> 
> thanks,
> jirka