Re: [PATCH ghak25 v3 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister
On Friday, April 17, 2020 5:53:47 PM EDT Paul Moore wrote:
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)
If this is the kernel, why is pid not 0? And if pid is 0, then isn't
exe=/boot/vmlinuz-X.Y.Z-blah?
> > > Given the precedent set by bpf unload, I'd really
rather drop this
> > > patch that adds subject credentials.
<snip>
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?
Yes, any change to information flow must be auditable.
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.
Exactly. But if someone does a search based on the fields, they need to be
able to find this record. For example, suppose I want to know what actions
have been performed by kernel_t, I can run a search and find this event.
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?
You can't search on the absense of information. There are some fields that
have meaning. It's OK if they are unset. It happens for daemons, too. But we
don't remove the fields because of it. It tells part of the story.
-Steve