BPF audit logs

BPF audit logs

[Burn Alting]

[-- Attachment #1.1: Type: text/plain, Size: 605 bytes --]

Hi,
I note that the unsolicited AUDIT_BPF audit event only provides a program id and
operation (load or unload). For example, 	type=BPF msg=audit(21/12/22
09:03:35.765:439) : prog-id=75 op=LOAD or	type=BPF msg=audit(21/12/22
09:04:05.883:460) : prog-id=0 op=UNLOAD
I also note that the bpf auxillary structure (struct bpf_prog_aux) that holds the
program id value, also holds a name (struct bpf_prog_aux->name) and uid  (struct
bpf_prog_aud->user_struct->uid). Perhaps adding these two items to the AUDIT_BPF
event would provide more security context for this unsolicited event.
Thoughts?
RgdsBurn Alting

[-- Attachment #1.2: Type: text/html, Size: 894 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: BPF audit logs

[Steve Grubb]

Hello Burn,

On Tuesday, December 20, 2022 5:36:28 PM EST Burn Alting wrote:
> I note that the unsolicited AUDIT_BPF audit event only provides a program
> id and operation (load or unload). For example, 	type=BPF
> msg=audit(21/12/22 09:03:35.765:439) : prog-id=75 op=LOAD or	type=BPF
> msg=audit(21/12/22 09:04:05.883:460) : prog-id=0 op=UNLOAD
> I also note that the bpf auxillary structure (struct bpf_prog_aux) that
> holds the program id value, also holds a name (struct bpf_prog_aux->name)
> and uid  (struct bpf_prog_aud->user_struct->uid). Perhaps adding these two
> items to the AUDIT_BPF event would provide more security context for this
> unsolicited event. Thoughts?

I agree that the resulting event leaves a lot to be desired. When the patch 
was being merged, I think it was pointed out that all we have is a number. 
The BPF folks seemed to insist that was all that was needed. They never 
explained how to use that number for anything practical like knowing what was 
loaded. If anything can be done to improve the situation, I'd like to 
encourage a patch. Systemd triggers a bunch of these events. But what it's 
doing is unknowable.

-Steve



--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: BPF audit logs

[Burn Alting]

[-- Attachment #1.1: Type: text/plain, Size: 1512 bytes --]

On Tue, 2022-12-20 at 18:16 -0500, Steve Grubb wrote:
> Hello Burn,
> 
> On Tuesday, December 20, 2022 5:36:28 PM EST Burn Alting wrote:
> > I note that the unsolicited AUDIT_BPF audit event only provides a program
> > id and operation (load or unload). For example, 	type=BPF
> > msg=audit(21/12/22 09:03:35.765:439) : prog-id=75 op=LOAD or	type=BPF
> > msg=audit(21/12/22 09:04:05.883:460) : prog-id=0 op=UNLOAD
> > I also note that the bpf auxillary structure (struct bpf_prog_aux) that
> > holds the program id value, also holds a name (struct bpf_prog_aux->name)
> > and uid  (struct bpf_prog_aud->user_struct->uid). Perhaps adding these two
> > items to the AUDIT_BPF event would provide more security context for this
> > unsolicited event. Thoughts?
> 
> I agree that the resulting event leaves a lot to be desired. When the patch 
> was being merged, I think it was pointed out that all we have is a number. 
> The BPF folks seemed to insist that was all that was needed. They never 
> explained how to use that number for anything practical like knowing what was 
> loaded. If anything can be done to improve the situation, I'd like to 
> encourage a patch. Systemd triggers a bunch of these events. But what it's 
> doing is unknowable.
> 
> -Steve

And to cap this off, the program id will always be zero on an UNLOAD, as
the routine that sets it to zero, kernel/bpf/syscall.c:bpf_prog_free_id(),
is called before the emit audit event routine, kernel/bpf/syscall.c:bpf_audit_prog().

So a bug!

Rgds

[-- Attachment #1.2: Type: text/html, Size: 2093 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: BPF audit logs

[Paul Moore]

On Tue, Dec 20, 2022 at 7:02 PM Burn Alting <burn.alting@iinet.net.au> wrote:
> And to cap this off, the program id will always be zero on an UNLOAD, as
> the routine that sets it to zero, kernel/bpf/syscall.c:bpf_prog_free_id(),
> is called before the emit audit event routine, kernel/bpf/syscall.c:bpf_audit_prog().
>
> So a bug!

Ooof :/  Independent of the other issues this is something we should
fix as soon as we can.  I'll take a look during the holiday and see
what we can do to fix this; looking quickly at it now I don't think it
will be too bad, but one never knows for sure ...

-- 
paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: BPF audit logs

[Paul Moore]

On Wed, Dec 21, 2022 at 9:44 AM Paul Moore <paul@paul-moore.com> wrote:
> On Tue, Dec 20, 2022 at 7:02 PM Burn Alting <burn.alting@iinet.net.au> wrote:
> > And to cap this off, the program id will always be zero on an UNLOAD, as
> > the routine that sets it to zero, kernel/bpf/syscall.c:bpf_prog_free_id(),
> > is called before the emit audit event routine, kernel/bpf/syscall.c:bpf_audit_prog().
> >
> > So a bug!
>
> Ooof :/  Independent of the other issues this is something we should
> fix as soon as we can.  I'll take a look during the holiday and see
> what we can do to fix this; looking quickly at it now I don't think it
> will be too bad, but one never knows for sure ...

I'm still just looking at the code, but I think we can also do a
better job associating eBPF UNLOAD operations.

-- 
paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: BPF audit logs

[Burn Alting]

[-- Attachment #1.1: Type: text/plain, Size: 1099 bytes --]

On Wed, 2022-12-21 at 09:54 -0500, Paul Moore wrote:
> On Wed, Dec 21, 2022 at 9:44 AM Paul Moore <paul@paul-moore.com> wrote:
> > On Tue, Dec 20, 2022 at 7:02 PM Burn Alting <burn.alting@iinet.net.au> wrote:
> > > And to cap this off, the program id will always be zero on an UNLOAD, asthe
> > > routine that sets it to zero, kernel/bpf/syscall.c:bpf_prog_free_id(),is
> > > called before the emit audit event routine,
> > > kernel/bpf/syscall.c:bpf_audit_prog().
> > > So a bug!
> > 
> > Ooof :/  Independent of the other issues this is something we shouldfix as soon
> > as we can.  I'll take a look during the holiday and seewhat we can do to fix
> > this; looking quickly at it now I don't think itwill be too bad, but one never
> > knows for sure ...
> 
> I'm still just looking at the code, but I think we can also do abetter job
> associating eBPF UNLOAD operations
As Steve suggests, it would have value to provide more information (name, tag, uid)
and I don't know if it's possible
but relate it to the bpf syscall's file descriptor for the map created or program
loaded (the exit value).

[-- Attachment #1.2: Type: text/html, Size: 1818 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: BPF audit logs

[Paul Moore]

On Wed, Dec 21, 2022 at 4:03 PM Burn Alting <burn@swtf.dyndns.org> wrote:
> As Steve suggests, it would have value to provide more information (name, tag, uid) and I don't know if it's possible
> but relate it to the bpf syscall's file descriptor for the map created or program loaded (the exit value).

I'm primarily focused on the bogus ID during load, as that is an
obvious regression that needs to be addressed as soon as possible.
For various backport/support reasons, I don't want to combine the bug
fix with the feature enhancement of adding new fields.

-- 
paul-moore.com

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: BPF audit logs

[Burn Alting]

[-- Attachment #1.1: Type: text/plain, Size: 636 bytes --]

On Wed, 2022-12-21 at 18:40 -0500, Paul Moore wrote:
> On Wed, Dec 21, 2022 at 4:03 PM Burn Alting <burn@swtf.dyndns.org> wrote:
> > As Steve suggests, it would have value to provide more information (name, tag,
> > uid) and I don't know if it's possiblebut relate it to the bpf syscall's file
> > descriptor for the map created or program loaded (the exit value).
> 
> I'm primarily focused on the bogus ID during load, as that is anobvious regression
> that needs to be addressed as soon as possible.For various backport/support
> reasons, I don't want to combine the bugfix with the feature enhancement of adding
> new fields.

Ack.

[-- Attachment #1.2: Type: text/html, Size: 1117 bytes --]

[-- Attachment #2: Type: text/plain, Size: 107 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit