From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: CONFIG_CHANGE record formats Date: Fri, 30 Mar 2018 13:20:47 -0400 Message-ID: <1906093.e7X4P2EiWg@x2> References: <20180322084246.ftjsyk4d5c4xx5u4@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180322084246.ftjsyk4d5c4xx5u4@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 Thursday, March 22, 2018 4:42:46 AM EDT Richard Guy Briggs wrote: > Hi Steve, Paul, > > Looking at some AUDIT_CONFIG_CHANGE record formats, a couple of things > stand out as potential problems: > > For ADD_RULE and DEL_RULE case when audit_enabled is in the AUDIT_LOCKED > state, it just outputs "audit_enabled=2 res=0" to indicate locked and > failure, but doesn't appear to actually give the normal "op=" to > indicate a rule change was attempted and refused due to immutability of > the rule set. Will this be a problem for the parser, and should an > attempted rule change be logged as such? If its the only rule change event that does not have an op= field, then make it have one. > The other is AUDIT_TTY_SET that has non-standard old-* and new-* fields, > but since there are two, I think it is unavoidable and can't be fixed. We actually have to have old and new values for any configuration change that is not a rule add/delete. For example, if we enable audit, we need the old and new values. This can be expressed either as old- new- or old- and the item without a new prefix. > Another is that other than a change to the enabled status and maybe > auditd PID changes, every other config change should not be logged if > audit is disabled. True. > Furthermore, if CONFIG_CHANGE records are to be accompanied by syscall > records, they should obey audit_dummy_context() to avoid unaccompanied > records. Does this reasoning make sense? CONFIG_CHANGE records are simple events and not compound events. They should contain all the pertinent information in their one record. -Steve