netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Paul Moore <paul@paul-moore.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-audit@redhat.com, Andrii Nakryiko <andriin@fb.com>,
	Yonghong Song <yhs@fb.com>, Martin KaFai Lau <kafai@fb.com>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Steve Grubb <sgrubb@redhat.com>, David Miller <davem@redhat.com>,
	Eric Paris <eparis@redhat.com>, Jiri Benc <jbenc@redhat.com>
Subject: Re: [PATCHv3] bpf: Emit audit messages upon successful prog load and unload
Date: Tue, 10 Dec 2019 00:19:51 +0100	[thread overview]
Message-ID: <d387184e-9c5f-d5b2-0acb-57b794235cbd@iogearbox.net> (raw)
In-Reply-To: <CAHC9VhQdOGTj1HT1cwvAdE1sRpzk5mC+oHQLHgJFa3vXEij+og@mail.gmail.com>

On 12/9/19 3:56 PM, Paul Moore wrote:
> On Mon, Dec 9, 2019 at 7:15 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On Fri, Dec 06, 2019 at 10:49:34PM +0100, Jiri Olsa wrote:
>>> From: Daniel Borkmann <daniel@iogearbox.net>
>>>
>>> Allow for audit messages to be emitted upon BPF program load and
>>> unload for having a timeline of events. The load itself is in
>>> syscall context, so additional info about the process initiating
>>> the BPF prog creation can be logged and later directly correlated
>>> to the unload event.
>>>
>>> The only info really needed from BPF side is the globally unique
>>> prog ID where then audit user space tooling can query / dump all
>>> info needed about the specific BPF program right upon load event
>>> and enrich the record, thus these changes needed here can be kept
>>> small and non-intrusive to the core.
>>>
>>> Raw example output:
>>>
>>>    # auditctl -D
>>>    # auditctl -a always,exit -F arch=x86_64 -S bpf
>>>    # ausearch --start recent -m 1334
>>>    ...
>>>    ----
>>>    time->Wed Nov 27 16:04:13 2019
>>>    type=PROCTITLE msg=audit(1574867053.120:84664): proctitle="./bpf"
>>>    type=SYSCALL msg=audit(1574867053.120:84664): arch=c000003e syscall=321   \
>>>      success=yes exit=3 a0=5 a1=7ffea484fbe0 a2=70 a3=0 items=0 ppid=7477    \
>>>      pid=12698 auid=1001 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001    \
>>>      egid=1001 sgid=1001 fsgid=1001 tty=pts2 ses=4 comm="bpf"                \
>>>      exe="/home/jolsa/auditd/audit-testsuite/tests/bpf/bpf"                  \
>>>      subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
>>>    type=UNKNOWN[1334] msg=audit(1574867053.120:84664): prog-id=76 op=LOAD
>>>    ----
>>>    time->Wed Nov 27 16:04:13 2019
>>>    type=UNKNOWN[1334] msg=audit(1574867053.120:84665): prog-id=76 op=UNLOAD
>>>    ...
>>>
>>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>>> Co-developed-by: Jiri Olsa <jolsa@kernel.org>
>>> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
>>
>> Paul, Steve, given the merge window is closed by now, does this version look
>> okay to you for proceeding to merge into bpf-next?
> 
> Given the change to audit UAPI I was hoping to merge this via the
> audit/next tree, is that okay with you?

Hm, my main concern is that given all the main changes are in BPF core and
usually the BPF subsystem has plenty of changes per release coming in that we'd
end up generating unnecessary merge conflicts. Given the include/uapi/linux/audit.h
UAPI diff is a one-line change, my preference would be to merge via bpf-next with
your ACK or SOB added. Does that work for you as well as?

Thanks,
Daniel

  reply	other threads:[~2019-12-09 23:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06 21:49 [PATCHv3] bpf: Emit audit messages upon successful prog load and unload Jiri Olsa
2019-12-09 12:15 ` Daniel Borkmann
2019-12-09 14:56   ` Paul Moore
2019-12-09 23:19     ` Daniel Borkmann [this message]
2019-12-09 23:53       ` Paul Moore
2019-12-10 15:36         ` Jiri Olsa
2019-12-10 22:45           ` Paul Moore
2019-12-11 13:19             ` Daniel Borkmann
2019-12-11 16:21               ` Paul Moore
2019-12-11 16:47                 ` Daniel Borkmann
2019-12-11 16:56                 ` Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d387184e-9c5f-d5b2-0acb-57b794235cbd@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=davem@redhat.com \
    --cc=eparis@redhat.com \
    --cc=jakub.kicinski@netronome.com \
    --cc=jbenc@redhat.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=linux-audit@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=sgrubb@redhat.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).