On 2020-03-18 17:22, Paul Moore wrote: > On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > > On 2020-03-17 17:30, Richard Guy Briggs wrote: > > > Some table unregister actions seem to be initiated by the kernel to > > > garbage collect unused tables that are not initiated by any userspace > > > actions. It was found to be necessary to add the subject credentials to > > > cover this case to reveal the source of these actions. A sample record: > > > > > > type=NETFILTER_CFG msg=audit(2020-03-11 21:25:21.491:269) : table=nat family=bridge entries=0 op=unregister pid=153 uid=root auid=unset tty=(none) ses=unset subj=system_u:system_r:kernel_t:s0 comm=kworker/u4:2 exe=(null) > > > > Given the precedent set by bpf unload, I'd really rather drop this patch > > that adds subject credentials. > > > > Similarly with ghak25's subject credentials, but they were already > > present and that would change an existing record format, so it isn't > > quite as justifiable in that case. > > Your comments have me confused - do you want this patch (v3 3/3) > considered for merging or no? I would like it considered for merging if you think it will be required to provide enough information about the event that happenned. In the bpf unload case, there is a program number to provide a link to a previous load action. In this case, we won't know for sure what caused the table to be unloaded if the number of entries was empty. I'm still trying to decide if it matters. For the sake of caution I think it should be included. I don't like it, but I think it needs to be included. > paul moore - RGB -- Richard Guy Briggs <rgb@xxxxxxxxxx> 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
