Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload

Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload

[Richard Guy Briggs]

On 2018-10-07 18:19, Jesper Dangaard Brouer wrote:
> On Sat, 6 Oct 2018 00:05:22 +0200
> Jiri Olsa <jolsa@redhat.com> wrote:
> 
> > On Fri, Oct 05, 2018 at 11:44:35AM -0700, Alexei Starovoitov wrote:
> > > On Fri, Oct 05, 2018 at 08:14:09AM +0200, Jiri Olsa wrote:  
> > > > On Thu, Oct 04, 2018 at 03:10:15PM -0700, Alexei Starovoitov wrote:  
> > > > > On Thu, Oct 04, 2018 at 10:22:31PM +0200, Jesper Dangaard Brouer wrote:  
> > > > > > On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
> > > > > >   
> > > > > > > On 10/04/2018 08:39 PM, Jesper Dangaard Brouer wrote:  
> > > > > > > > On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:    
> > > > > > > >> On Thu, Oct 04, 2018 at 03:50:38PM +0200, Daniel Borkmann wrote:    
> > > > > > [...]  
> > > > > > > >>
> > > > > > > >> If the purpose of the patch is to give user space visibility into
> > > > > > > >> bpf prog load/unload as a notification, then I completely agree that
> > > > > > > >> some notification mechanism is necessary.    
> > > > > > > 
> > > > > > > Yeah, I did only regard it as only that, nothing more. Some means
> > > > > > > of timeline and notification that can be kept in a record in user
> > > > > > > space and later retrieved e.g. for introspection on what has been
> > > > > > > loaded.
> > > > > > >   
> > > > > > > >> I've started working on such mechanism via perf ring buffer which is
> > > > > > > >> the fastest mechanism we have in the kernel so far.
> > > > > > > >> See long discussion here: https://patchwork.ozlabs.org/patch/971970/    
> > > > 
> [...]
> > > > > > > 
> > > > > > > That one is definitely needed in any case to resolve the kallsyms
> > > > > > > limitations, and it does have overlap in that in either case we
> > > > > > > want to look at past BPF programs that have been unloaded in the
> > > > > > > meantime, so I don't have a strong preference either way, and the
> > > > > > > former is needed in any case. Though thought was that audit might
> > > > > > > be an option for those not running profiling daemons 24/7, but
> > > > > > > presumably bpftool could be extended to record these events as
> > > > > > > well if we don't want to reuse audit infra.  
> > > > > > 
> > > > > > Yes, exactly, I don't want to run a profiling daemon 24/7 to record
> > > > > > these events.  I do acknowledge that this perf event is relevant,
> > > > > > especially for catching the kernel symbols (I need that myself), but it
> > > > > > does not cover my use-case.
> > > > > > 
> > > > > > My use-case is to 24/7 collect and keep records in userspace, and have a
> > > > > > timeline of these notifications, for later retrieval.  The idea is that
> > > > > > our support engineers can look at these records when troubleshooting
> > > > > > the system.  And the plan is also to collect these records as part of
> > > > > > our sosreport tool, which is part of the support case.  
> > > > > 
> > > > > I don't think you're implying that prog load/unload should be spamming dmesg
> > > > > and auditd not even running...  
> > > > 
> > > > I think the problem Jesper implied is that in order to collect
> > > > those logs you'll need perf tool running all the time.. which
> > > > it's not equipped for yet  
> > > 
> > > I'm not proposing to run 'perf' binary all the time.
> > > Setting up perf ring buffer just for these new bpf prog load/unload events
> > > and epolling it is simple enough to do from any application including auditd.
> > > selftests/bpf/ do it for bpf output events.  
> > 
> > ok, did not think about the possibility to teach auditd talk to perf,
> > time to get that tool evsel/evlist/rb library ready ;-)
> 
> Interesting, I also didn't consider teaching auditd to gets its 'bpf'
> events from a separate perf ring-buffer, that might work.  I do wonder
> how the audit people will take this suggestion.

Including the linux-audit list to get userspace audit folks in the
loop...

> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer

- RGB

Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload

[Steve Grubb]

On Thursday, October 18, 2018 3:53:06 PM EDT Richard Guy Briggs wrote:
> On 2018-10-07 18:19, Jesper Dangaard Brouer wrote:
> > On Sat, 6 Oct 2018 00:05:22 +0200
> > 
> > Jiri Olsa <jolsa@redhat.com> wrote:
> > > On Fri, Oct 05, 2018 at 11:44:35AM -0700, Alexei Starovoitov wrote:
> > > > On Fri, Oct 05, 2018 at 08:14:09AM +0200, Jiri Olsa wrote:
> > > > > On Thu, Oct 04, 2018 at 03:10:15PM -0700, Alexei Starovoitov wrote:
> > > > > > On Thu, Oct 04, 2018 at 10:22:31PM +0200, Jesper Dangaard Brouer 
wrote:
> > > > > > > On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann 
<daniel@iogearbox.net> wrote:
> > > > > > > > On 10/04/2018 08:39 PM, Jesper Dangaard Brouer wrote:
> > > > > > > > > On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov 
<alexei.starovoitov@gmail.com> wrote:
> > > > > > > > >> On Thu, Oct 04, 2018 at 03:50:38PM +0200, Daniel Borkmann 
wrote:
> > > > > > > [...]
> > > > > > > 
> > > > > > > > >> If the purpose of the patch is to give user space
> > > > > > > > >> visibility into
> > > > > > > > >> bpf prog load/unload as a notification, then I completely
> > > > > > > > >> agree that
> > > > > > > > >> some notification mechanism is necessary.
> > > > > > > > 
> > > > > > > > Yeah, I did only regard it as only that, nothing more. Some
> > > > > > > > means
> > > > > > > > of timeline and notification that can be kept in a record in
> > > > > > > > user
> > > > > > > > space and later retrieved e.g. for introspection on what has
> > > > > > > > been
> > > > > > > > loaded.
> > > > > > > > 
> > > > > > > > >> I've started working on such mechanism via perf ring
> > > > > > > > >> buffer which is
> > > > > > > > >> the fastest mechanism we have in the kernel so far.
> > > > > > > > >> See long discussion here:
> > > > > > > > >> https://patchwork.ozlabs.org/patch/971970/
> > 
> > [...]
> > 
> > > > > > > > That one is definitely needed in any case to resolve the
> > > > > > > > kallsyms
> > > > > > > > limitations, and it does have overlap in that in either case
> > > > > > > > we
> > > > > > > > want to look at past BPF programs that have been unloaded in
> > > > > > > > the
> > > > > > > > meantime, so I don't have a strong preference either way, and
> > > > > > > > the
> > > > > > > > former is needed in any case. Though thought was that audit
> > > > > > > > might
> > > > > > > > be an option for those not running profiling daemons 24/7,
> > > > > > > > but
> > > > > > > > presumably bpftool could be extended to record these events
> > > > > > > > as
> > > > > > > > well if we don't want to reuse audit infra.
> > > > > > > 
> > > > > > > Yes, exactly, I don't want to run a profiling daemon 24/7 to
> > > > > > > record
> > > > > > > these events.  I do acknowledge that this perf event is
> > > > > > > relevant,
> > > > > > > especially for catching the kernel symbols (I need that
> > > > > > > myself), but it
> > > > > > > does not cover my use-case.
> > > > > > > 
> > > > > > > My use-case is to 24/7 collect and keep records in userspace,
> > > > > > > and have a
> > > > > > > timeline of these notifications, for later retrieval.  The idea
> > > > > > > is that
> > > > > > > our support engineers can look at these records when
> > > > > > > troubleshooting
> > > > > > > the system.  And the plan is also to collect these records as
> > > > > > > part of
> > > > > > > our sosreport tool, which is part of the support case.
> > > > > > 
> > > > > > I don't think you're implying that prog load/unload should be
> > > > > > spamming dmesg and auditd not even running...
> > > > > 
> > > > > I think the problem Jesper implied is that in order to collect
> > > > > those logs you'll need perf tool running all the time.. which
> > > > > it's not equipped for yet
> > > > 
> > > > I'm not proposing to run 'perf' binary all the time.
> > > > Setting up perf ring buffer just for these new bpf prog load/unload
> > > > events and epolling it is simple enough to do from any application
> > > > including auditd. selftests/bpf/ do it for bpf output events.
> > > 
> > > ok, did not think about the possibility to teach auditd talk to perf,
> > > time to get that tool evsel/evlist/rb library ready ;-)
> > 
> > Interesting, I also didn't consider teaching auditd to gets its 'bpf'
> > events from a separate perf ring-buffer, that might work.  I do wonder
> > how the audit people will take this suggestion.

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

-Steve