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

[Richard Guy Briggs]

On 2019-04-16 16:18, Steve Grubb wrote:
> 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.

There are still 8 arches or so that are in this case.

> > > > 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.

Ok, so all of these messages I am fixing were needlessly printing the
subj field anyways?  This is easy to fix with this patch.

> -Steve

- RGB

--
Richard Guy Briggs <rgb at redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635