Discussion:
[PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload
Richard Guy Briggs
2018-10-18 19:53:06 UTC
Permalink
On Sat, 6 Oct 2018 00:05:22 +0200
[...]
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

--
Richard Guy Briggs <***@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
Steve Grubb
2018-10-18 22:09:01 UTC
Permalink
On Sat, 6 Oct 2018 00:05:22 +0200
On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann
On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov
[...]
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.
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

Loading...