| Message ID | 20191206214934.11319-1-jolsa@kernel.org |
|---|---|
| State | Accepted |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | [PATCHv3] bpf: Emit audit messages upon successful prog load and unload | expand |
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? Thanks, Daniel
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?
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
On Mon, Dec 9, 2019 at 6:19 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > 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? I regularly (a few times a week) run the audit and SELinux tests against Linus+audit/next+selinux/next to make sure things are working as expected and that some other subsystem has introduced a change which has broken something. If you are willing to ensure the tests get run, including your new BPF audit tests I would be okay with that; is that acceptable?
On Mon, Dec 09, 2019 at 06:53:23PM -0500, Paul Moore wrote: > On Mon, Dec 9, 2019 at 6:19 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > 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? > > I regularly (a few times a week) run the audit and SELinux tests > against Linus+audit/next+selinux/next to make sure things are working > as expected and that some other subsystem has introduced a change > which has broken something. If you are willing to ensure the tests > get run, including your new BPF audit tests I would be okay with that; > is that acceptable? hi, would you please let me know which tree this landed at the end? thanks, jirka
On Tue, Dec 10, 2019 at 10:37 AM Jiri Olsa <jolsa@redhat.com> wrote: > On Mon, Dec 09, 2019 at 06:53:23PM -0500, Paul Moore wrote: > > On Mon, Dec 9, 2019 at 6:19 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > > 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? > > > > I regularly (a few times a week) run the audit and SELinux tests > > against Linus+audit/next+selinux/next to make sure things are working > > as expected and that some other subsystem has introduced a change > > which has broken something. If you are willing to ensure the tests > > get run, including your new BPF audit tests I would be okay with that; > > is that acceptable? > > hi, > would you please let me know which tree this landed at the end? I think that's what we are trying to figure out - Daniel?
On Tue, Dec 10, 2019 at 05:45:59PM -0500, Paul Moore wrote: > On Tue, Dec 10, 2019 at 10:37 AM Jiri Olsa <jolsa@redhat.com> wrote: > > On Mon, Dec 09, 2019 at 06:53:23PM -0500, Paul Moore wrote: > > > On Mon, Dec 9, 2019 at 6:19 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > > > 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? > > > > > > I regularly (a few times a week) run the audit and SELinux tests > > > against Linus+audit/next+selinux/next to make sure things are working > > > as expected and that some other subsystem has introduced a change > > > which has broken something. If you are willing to ensure the tests > > > get run, including your new BPF audit tests I would be okay with that; > > > is that acceptable? > > > > would you please let me know which tree this landed at the end? > > I think that's what we are trying to figure out - Daniel? Yeah, sounds reasonable wrt running tests to make sure nothing breaks. In that case I'd wait for your ACK or SOB to proceed with merging into bpf-next. Thanks Paul!
On Wed, Dec 11, 2019 at 8:20 AM Daniel Borkmann <daniel@iogearbox.net> wrote: > On Tue, Dec 10, 2019 at 05:45:59PM -0500, Paul Moore wrote: > > On Tue, Dec 10, 2019 at 10:37 AM Jiri Olsa <jolsa@redhat.com> wrote: > > > On Mon, Dec 09, 2019 at 06:53:23PM -0500, Paul Moore wrote: > > > > On Mon, Dec 9, 2019 at 6:19 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > > > > 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? > > > > > > > > I regularly (a few times a week) run the audit and SELinux tests > > > > against Linus+audit/next+selinux/next to make sure things are working > > > > as expected and that some other subsystem has introduced a change > > > > which has broken something. If you are willing to ensure the tests > > > > get run, including your new BPF audit tests I would be okay with that; > > > > is that acceptable? > > > > > > would you please let me know which tree this landed at the end? > > > > I think that's what we are trying to figure out - Daniel? > > Yeah, sounds reasonable wrt running tests to make sure nothing breaks. In that > case I'd wait for your ACK or SOB to proceed with merging into bpf-next. Thanks > Paul! As long as you're going to keep testing this, here ya go :) Acked-by: Paul Moore <paul@paul-moore.com> (also, go ahead and submit that PR for audit-testsuite - thanks!)
On Wed, Dec 11, 2019 at 11:21:33AM -0500, Paul Moore wrote: > On Wed, Dec 11, 2019 at 8:20 AM Daniel Borkmann <daniel@iogearbox.net> wrote: > > On Tue, Dec 10, 2019 at 05:45:59PM -0500, Paul Moore wrote: > > > On Tue, Dec 10, 2019 at 10:37 AM Jiri Olsa <jolsa@redhat.com> wrote: > > > > On Mon, Dec 09, 2019 at 06:53:23PM -0500, Paul Moore wrote: > > > > > On Mon, Dec 9, 2019 at 6:19 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > > > > > 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? > > > > > > > > > > I regularly (a few times a week) run the audit and SELinux tests > > > > > against Linus+audit/next+selinux/next to make sure things are working > > > > > as expected and that some other subsystem has introduced a change > > > > > which has broken something. If you are willing to ensure the tests > > > > > get run, including your new BPF audit tests I would be okay with that; > > > > > is that acceptable? > > > > > > > > would you please let me know which tree this landed at the end? > > > > > > I think that's what we are trying to figure out - Daniel? > > > > Yeah, sounds reasonable wrt running tests to make sure nothing breaks. In that > > case I'd wait for your ACK or SOB to proceed with merging into bpf-next. Thanks > > Paul! > > As long as you're going to keep testing this, here ya go :) > > Acked-by: Paul Moore <paul@paul-moore.com> > > (also, go ahead and submit that PR for audit-testsuite - thanks!) Perfect, thanks for all your help! Applied to bpf-next.
On Wed, Dec 11, 2019 at 11:21:33AM -0500, Paul Moore wrote: > On Wed, Dec 11, 2019 at 8:20 AM Daniel Borkmann <daniel@iogearbox.net> wrote: > > On Tue, Dec 10, 2019 at 05:45:59PM -0500, Paul Moore wrote: > > > On Tue, Dec 10, 2019 at 10:37 AM Jiri Olsa <jolsa@redhat.com> wrote: > > > > On Mon, Dec 09, 2019 at 06:53:23PM -0500, Paul Moore wrote: > > > > > On Mon, Dec 9, 2019 at 6:19 PM Daniel Borkmann <daniel@iogearbox.net> wrote: > > > > > > 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? > > > > > > > > > > I regularly (a few times a week) run the audit and SELinux tests > > > > > against Linus+audit/next+selinux/next to make sure things are working > > > > > as expected and that some other subsystem has introduced a change > > > > > which has broken something. If you are willing to ensure the tests > > > > > get run, including your new BPF audit tests I would be okay with that; > > > > > is that acceptable? > > > > > > > > would you please let me know which tree this landed at the end? > > > > > > I think that's what we are trying to figure out - Daniel? > > > > Yeah, sounds reasonable wrt running tests to make sure nothing breaks. In that > > case I'd wait for your ACK or SOB to proceed with merging into bpf-next. Thanks > > Paul! > > As long as you're going to keep testing this, here ya go :) > > Acked-by: Paul Moore <paul@paul-moore.com> > > (also, go ahead and submit that PR for audit-testsuite - thanks!) https://github.com/linux-audit/audit-testsuite/pull/90 thanks, jirka
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h index c89c6495983d..32a5db900f47 100644 --- a/include/uapi/linux/audit.h +++ b/include/uapi/linux/audit.h @@ -116,6 +116,7 @@ #define AUDIT_FANOTIFY 1331 /* Fanotify access decision */ #define AUDIT_TIME_INJOFFSET 1332 /* Timekeeping offset injected */ #define AUDIT_TIME_ADJNTPVAL 1333 /* NTP value adjustment */ +#define AUDIT_BPF 1334 /* BPF subsystem */ #define AUDIT_AVC 1400 /* SE Linux avc denial or grant */ #define AUDIT_SELINUX_ERR 1401 /* Internal SE Linux Errors */ diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index e3461ec59570..66b90eaf99fe 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -23,6 +23,7 @@ #include <linux/timekeeping.h> #include <linux/ctype.h> #include <linux/nospec.h> +#include <linux/audit.h> #include <uapi/linux/btf.h> #define IS_FD_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY || \ @@ -1306,6 +1307,36 @@ static int find_prog_type(enum bpf_prog_type type, struct bpf_prog *prog) return 0; } +enum bpf_audit { + BPF_AUDIT_LOAD, + BPF_AUDIT_UNLOAD, + BPF_AUDIT_MAX, +}; + +static const char * const bpf_audit_str[BPF_AUDIT_MAX] = { + [BPF_AUDIT_LOAD] = "LOAD", + [BPF_AUDIT_UNLOAD] = "UNLOAD", +}; + +static void bpf_audit_prog(const struct bpf_prog *prog, unsigned int op) +{ + struct audit_context *ctx = NULL; + struct audit_buffer *ab; + + if (WARN_ON_ONCE(op >= BPF_AUDIT_MAX)) + return; + if (audit_enabled == AUDIT_OFF) + return; + if (op == BPF_AUDIT_LOAD) + ctx = audit_context(); + ab = audit_log_start(ctx, GFP_ATOMIC, AUDIT_BPF); + if (unlikely(!ab)) + return; + audit_log_format(ab, "prog-id=%u op=%s", + prog->aux->id, bpf_audit_str[op]); + audit_log_end(ab); +} + int __bpf_prog_charge(struct user_struct *user, u32 pages) { unsigned long memlock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT; @@ -1421,6 +1452,7 @@ static void __bpf_prog_put(struct bpf_prog *prog, bool do_idr_lock) { if (atomic64_dec_and_test(&prog->aux->refcnt)) { perf_event_bpf_event(prog, PERF_BPF_EVENT_PROG_UNLOAD, 0); + bpf_audit_prog(prog, BPF_AUDIT_UNLOAD); /* bpf_prog_free_id() must be called first */ bpf_prog_free_id(prog, do_idr_lock); __bpf_prog_put_noref(prog, true); @@ -1830,6 +1862,7 @@ static int bpf_prog_load(union bpf_attr *attr, union bpf_attr __user *uattr) */ bpf_prog_kallsyms_add(prog); perf_event_bpf_event(prog, PERF_BPF_EVENT_PROG_LOAD, 0); + bpf_audit_prog(prog, BPF_AUDIT_LOAD); err = bpf_prog_new_fd(prog); if (err < 0)