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@xxxxxxxxxx> wrote: > > 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) 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
