Re: [PATCH ghau90 v1] sig_info: use standard template for log messages

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday, April 16, 2019 3:57:51 PM EDT Richard Guy Briggs wrote:
> On 2019-04-15 17:10, Steve Grubb wrote:
> > On Monday, April 15, 2019 12:21:49 PM EDT Richard Guy Briggs wrote:
> > > On 2019-04-15 10:58, Steve Grubb wrote:
> > > > On Monday, April 15, 2019 9:02:36 AM EDT Richard Guy Briggs wrote:
> > > > > Records that are triggered by an AUDIT_SIGNAL_INFO message
> > > > > including
> > > > > AUDIT_DAEMON_CONFIG (HUP), AUDIT_DAEMON_ROTATE (USR1),
> > > > > AUDIT_DAEMON_RESUME (USR2) and AUDIT_DAEMON_END (TERM) have
> > > > > inconsistent reporting of signal info and swinging field "state".
> > > > 
> > > > This is crusty old code that has things in it that were for
> > > > migrations with very old kernels. It's not readily obvious because
> > > > those kernel transitions were quite some time ago. There was also a
> > > > fake
> > > > 
> > > > > They also assume that an empty security context implies there is no
> > > > > other useful information in the AUDIT_SIGNAL_INFO message so don't
> > > > > use the information that is there.
> > > > 
> > > > How are you generating the events that trigger this? If this is based
> > > > on  reading the source code, I think its because of an ancient kernel
> > > > change. If you can generate this condition, then I'd like to
> > > > replicate the problem on my system to see what's happening.
> > > 
> > > I used a current audit/next kernel, compiled with AUDIT_CONFIG, but
> > > with and without AUDIT_CONFIGSYSCALL
> > 
> > Is this a configuration that we really want to support?  :-)  This really
> > will not work as anything except for gathering AVC's or other LSM
> > events. And I think those go to syslog anyways. I'd say that with this
> > kernel configuration, they likely would not run auditd as there's no
> > point in it.
> 
> Audit still works without CONFIGSYSCALL but is more limited.

I really don't think we should cater to that use case. I am willing to go 
with a consolidated logging function. With the caveat below.

> > > and simply signalled the audit daemon with the four signals and then
> > > ran  ausearch on the most recent messages.
> > > 
> > > I did not generate errors, but I could have by creating a custom kernel
> > > that returned errors upon request for AUDIT_SIGNAL_INFO.
> > > 
> > > > > Normalize AUDIT_DAEMON_CONFIG to use the value "reconfigure" and
> > > > > add the "state" field where missing.
> > > > > 
> > > > > Use audit_sig_info values when available, not making assumptions
> > > > > about their availability when the security context is absent.
> > > > > 
> > > > > See: https://github.com/linux-audit/audit-userspace/issues/90
> > > > 
> > > > I had made changes to the git repo Saturday. I suspect this patch
> > > > does not apply. I like the op value changes. That part I can go along
> > > > with. Shall I just make that adjustment in the upstream repo and we
> > > > can talk  more about how you are creating these events?
> > > 
> > > This patch was rebased on your patch so it is current.
> > 
> > One thing I should mention, the audit events are created with and without
> > the subj field because for common criteria, a DAC based system should
> > have no notion of MAC fields. This is why we alway branch on the "ctx"
> > variables and create the event with or without subj.
> 
> The only branch is whether or not to print "?" for the subj field, so
> the field is still always there.

But we don't want subj there at all if its a DAC only system.

-Steve