On Wed, Mar 18, 2020 at 5:33 PM Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2020-03-18 17:22, Paul Moore wrote:
> On Wed, Mar 18, 2020 at 9:12 AM Richard Guy Briggs <rgb(a)redhat.com> 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.
I'm in the middle of building patches 1/3 and 2/3, assuming all goes
well I'll merge them into audit/next (expect mail soon), however I'm
going back and forth on this patch. Like you I kinda don't like it,
and with both of us not in love with this patch I have to ask if there
is certification requirement for this? I know about the generic
subj/obj requirements, but in the case where there is no associated
task/syscall/etc. information it isn't like the extra fields supplied
in this patch are going to have much information in that regard; it's
really the *absence* of that information which is telling. Which
brings me to wonder if simply the lack of any associated records in
this event is enough? Before when we weren't associating records into
a single event it would have been a problem, but the way things
currently are, if there are no other records (and you have configured
that) then I think you have everything you need to know.
Thoughts?
--
paul moore
www.paul-moore.com