From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Benc Subject: Re: [RFC] audit support for BPF notification Date: Mon, 4 Nov 2019 14:05:18 +0100 Message-ID: <20191104140518.67471654@redhat.com> References: <20190809141831.GB9377@krava> <2985228.9kGasGrDWd@x2> <20190812075922.GA3012@krava> <5293423.BmRMD7FMx9@x2> <20190812143257.GC23992@krava> <20190814073323.GA16363@krava> <20190820135453.GH24105@krava> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20190820135453.GH24105@krava> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Jiri Olsa Cc: Arnaldo, Rashid Khan , Kozina , Yauheni Kaliuta , Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= , Carvalho de Melo , linux-audit@redhat.com, Jesper Dangaard Brouer , Petr Matousek , Stanislav, Vlad Dronov List-Id: linux-audit@redhat.com Seems there have been no reply to this...=20 Jiri, what is the current status? Vlad, what is the Product Security's view on this? Is the audit support for bpf programs loading/unloading a requirement for full support of eBPF (as opposed to tech preview)? Thanks, Jiri On Tue, 20 Aug 2019 15:54:53 +0200, Jiri Olsa wrote: > cc-ing Petr Matousek >=20 > jirka >=20 > On Wed, Aug 14, 2019 at 09:33:34AM +0200, Jiri Olsa wrote: > > hi, > > Adding Vlad Dronov to the loop, because he asked > > about this functionality some time ago. > >=20 > > Vlad, the full thread can be found in here: > > https://www.redhat.com/archives/linux-audit/2019-August/msg00004.html > >=20 > > Any thoughts on this? > >=20 > > thanks, > > jirka > >=20 > > On Mon, Aug 12, 2019 at 04:33:10PM +0200, Jiri Olsa wrote: =20 > > > On Mon, Aug 12, 2019 at 09:49:43AM -0400, Steve Grubb wrote: =20 > > > > On Monday, August 12, 2019 3:59:22 AM EDT Jiri Olsa wrote: =20 > > > > > On Fri, Aug 09, 2019 at 01:45:21PM -0400, Steve Grubb wrote: =20 > > > > > > Hello, > > > > > >=20 > > > > > > On Friday, August 9, 2019 10:18:31 AM EDT Jiri Olsa wrote: =20 > > > > > > > I posted initial change that allows auditd to log BPF program > > > > > > >=20 > > > > > > > load/unload events, it's in here: > > > > > > > https://github.com/linux-audit/audit-userspace/pull/104 =20 > > > > > >=20 > > > > > > Thanks for the patch...but we probably should have talked a bit= more > > > > > > before undertaking this effort. We normally do not audit from u= ser space > > > > > > what happens in the kernel. Doing this can be racy and it keeps= auditd > > > > > > from doing the one job it has - which is to grab events and rec= ord them > > > > > > to disk and send them out the realtime interface. > > > > > > =20 > > > > > > > We tried to push pure AUDIT interface for BPF program notific= ation, > > > > > > >=20 > > > > > > > but it was denied, the discussion is in here: > > > > > > > https://marc.info/?t=3D153866123200003&r=3D1&w=3D2 =20 > > > > > >=20 > > > > > > Hmm. The email I remember was here: > > > > > > https://www.redhat.com/archives/linux-audit/2018-October/msg000= 53.html > > > > > >=20 > > > > > > and was only 2 emails long with no answer to my question. :-) = =20 > > > > >=20 > > > > > oops, sry about that, your question was: =20 > > > > > =09> I'm not sure exactly what the issue is. You can audit for sp= ecific > > > > > =09> syscall > > > > > =09> and argument. So, if you want to see loads, then you can mak= e a rule > > > > > =09> like: > > > > > =09>=20 > > > > > =09> -a always,exit -F arch=3Db64 -S bpf -F a0=3D5 =20 > > > > >=20 > > > > > The problem with above for us is that we also: > > > > >=20 > > > > > - need to log also other properties of the BPF program, > > > > > which are not visible from BPF syscall arguments, like > > > > > its ID, JIT status =20 > > > >=20 > > > > The way this is normally done is to add a supplemental record. For = example,=20 > > > > when auditing the open syscall, we also get CWD & PATH supplemental= records.=20 > > > > When auditing connect, we get a SOCKADDR supplemental record. We ha= ve=20 > > > > requirements around selective audit whereby the admin is in control= of what=20 > > > > is selected for audit via audit rules. So, what one could do is set= a rule=20 > > > > for the bpf syscall and then when it triggers, we get these other r= ecords=20 > > > > added to the bpf syscall event. =20 > > >=20 > > > right, that was the initial plan, but BPF guys wanted just > > > single notification system without specific hooks for audit, > > > so we ended up with perf specific interface > > > =20 > > > > > or license info =20 > > > >=20 > > > > This ^^ is not a security issue. > > > >=20 > > > > =20 > > > > > - need to see BPF program UNLOAD, which is not done > > > > > via syscall, so those would be unvisible at all =20 > > > >=20 > > > > Is there a place in the kernel where this happens? I could see abno= rmal=20 > > > > termination being something we might want. Does the program go thro= ugh=20 > > > > something like an exit syscall internally? =20 > > >=20 > > > it's happening in here (kernel/bpf/syscall.c): > > >=20 > > > =09bpf_prog_put > > > =09 __bpf_prog_put > > > =09 { > > > =09=09 if (atomic_dec_and_test(&prog->aux->refcnt)) { > > > =09=09=09perf_event_bpf_event(prog, PERF_BPF_EVENT_PROG_UNLOAD, 0); > > > =09=09=09... > > > =09 } > > >=20 > > > BPF program is released when it drops the reference count, > > > which is normally when its file descriptor is closed. > > >=20 > > > However it might get pinned and stay alive even when the initial > > > file descriptor is closed.. and then there's the networking world, > > > which might have some other specific ways.. but it all ends up > > > in bpf_prog_put and zero reference count. > > > =20 > > > > > > > The outcome of the discussion was to use perf event interface > > > > > > > for BPF notification and use it in some deamon.. audit was ou= r > > > > > > > first choice. > > > > > > >=20 > > > > > > > thoughts? =20 > > > > > >=20 > > > > > > I'd like to understand what the basic problem is that needs to = be solved. =20 > > > > >=20 > > > > > we need a way for administrators to see the history of loaded BPF > > > > > programs, to help investigating issues related to BPF.. and the > > > > > only BPF interface for this data is through perf ring buffer =20 > > > >=20 > > > > That is really not the audit way. Let's keep talking to see where t= his ends=20 > > > > up. =20 > > >=20 > > > Would you see some other auditing daemon/app in place for this kind o= f data? > > >=20 > > > thanks, > > > jirka =20