On Sun, May 17, 2020 at 10:15 AM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > On 2020-04-28 18:25, Paul Moore wrote: > > On Wed, Apr 22, 2020 at 5:40 PM Richard Guy Briggs <rgb@xxxxxxxxxx> 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) > > > > [I'm going to comment up here instead of in the code because it is a > > bit easier for everyone to see what the actual impact might be on the > > records.] > > > > Steve wants subject info in this case, okay, but let's try to trim out > > some of the fields which simply don't make sense in this record; I'm > > thinking of fields that are unset/empty in the kernel case and are > > duplicates of other records in the userspace/syscall case. I think > > that means we can drop "tty", "ses", "comm", and "exe" ... yes? > > > > While "auid" is a potential target for removal based on the > > dup-or-unset criteria, I think it falls under Steve's request for > > subject info here, even if it is garbage in this case. > > Can you explain why auid falls under this criteria but ses does not if > both are unset? "While "auid" is a potential target for removal based on the dup-or-unset criteria, I think it falls under Steve's request for subject info here, even if it is garbage in this case." It's a concession to Steve. As I mentioned previously, I think the subject info is bogus in this case; either it is valid and we get it from the SYSCALL record or it simply isn't present in any meaningful way. -- paul moore www.paul-moore.com
