Re: [PATCH ghak122 v1] audit: store event sockaddr in case of no rules
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(a)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(a)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(a)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.