[PATCH ghak25 v4 3/3] audit: add subj creds to NETFILTER_CFG record to cover async unregister

[Paul Moore]

On Sun, May 17, 2020 at 2:26 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 5/17/2020 7:15 AM, Richard Guy Briggs wrote:
> > On 2020-04-28 18:25, Paul Moore wrote:
> >> On Wed, Apr 22, 2020 at 5:40 PM Richard Guy Briggs <rgb at redhat.com> 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?  If auid is unset then we know ses is unset?  If subj
> > contains *:kernel_t:* then uid can also be dropped even though it is
> > set, no?
>
> That's going to be up to the security module. SELinux may know that a
> task with a subj= *:kernel_t:* doesn't need an uid, but that's not
> going to be true with Smack, or if in the (distant?) future you
> have both SELinux and Smack. Creating a way for the security module
> to inform the audit system that it believes fields are unnecessary
> sounds tricky. Not to mention that it's likely to create cases where
> the audit user-space has to know which, if any, security modules are
> active.

It is important to remember that in the case we are talking about here
the record/event is not triggered by any user action so there is
limited to no useful subject information to log.  There *may* be an
argument to be made for logging the LSM subject info (although I
personally feel that to be a weak argument), but there is no reason to
log any of the traditional DAC UID/GID/etc. subject info as it simply
doesn't exist in this case.  When the UID/GID/etc. information does
exist, it would be logged via other records in the same event, e.g.
the SYSCALL record.

-- 
paul moore
www.paul-moore.com