[PATCH ghak122 v1] audit: store event sockaddr in case of no rules

[Steve Grubb]

On Monday, July 13, 2020 6:30:51 PM EDT Paul Moore wrote:
> On Mon, Jul 13, 2020 at 1:40 PM Richard Guy Briggs <rgb at redhat.com> wrote:
> > On 2020-07-08 18:49, Paul Moore wrote:
> > > On Fri, Jul 3, 2020 at 1:18 PM Richard Guy Briggs <rgb at redhat.com> 
wrote:
> > > > When there are no rules present, the event SOCKADDR record is not
> > > > generated due to audit_dummy_context() generated at syscall entry
> > > > from
> > > > audit_n_rules.  Store this information if there is a context present
> > > > to
> > > > store it so that mandatory events are more complete (startup,
> > > > LSMs...).
> > > > 
> > > > Please see the upstream issue
> > > > https://github.com/linux-audit/audit-kernel/issues/122
> > > > 
> > > > Signed-off-by: Richard Guy Briggs <rgb at redhat.com>
> > > > ---
> > > > Passes audit-testsuite.
> > > > 
> > > > include/linux/audit.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > Do we have any certification requirements driving this change?  I ask
> > > because if we make this change, why not do the same for PATH records?
> > 
> > I filed the issue because I noticed the SOCKADDR record missing from
> > configuration events required for certification.
> 
> I guess my original question wasn't very clear, let me try again ...
> 
> Do we have any certification requirements for this that require the
> SOCKADDR record without an explicit audit configuration that would
> capture/generate the sockaddr information? 

No. There is no need to include either the SYSCALL or SOCKADDR record when 
logging an audit config change event because it will always be sendto and 
netlink. I suppose this is being done for consistency and not due to 
certification. We just need the usual minimal information logged and nothing 
else.

-Steve


> It's been a while since
> I've been involved in a certification effort, but if I remember
> correctly those efforts required a specific audit configuration to be
> compliant (file watches, syscall rules, etc.).
> 
> If there is a certification requirement for this, it might be a good
> idea to include it in the commit description.  I don't believe we've
> been very good about doing that in the past, but it seems like
> something that would be worthwhile.