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

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