From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [PATCH ghau90 v1] sig_info: use standard template for log messages Date: Tue, 16 Apr 2019 16:18:06 -0400 Message-ID: <2504845.A2svE6jNlu@x2> References: <1555333356-24758-1-git-send-email-rgb@redhat.com> <2747424.UjTgPm6LFd@x2> <20190416195751.p4fbstmeqswxegcr@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190416195751.p4fbstmeqswxegcr@madcap2.tricolour.ca> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Richard Guy Briggs Cc: Linux-Audit Mailing List List-Id: linux-audit@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