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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181004222231.2edd5add@redhat.com>
Date:   Thu, 4 Oct 2018 22:22:31 +0200
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>, ast@...nel.org,
        netdev@...r.kernel.org, Jiri Olsa <jolsa@...nel.org>,
        acme@...nel.org, brouer@...hat.com
Subject: Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog
 load and unload

On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann <daniel@...earbox.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@...il.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.

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