From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: [RFC PATCH ghak10 2/3] audit: Add the audit_adjtime() function Date: Tue, 19 Jun 2018 16:52:06 -0400 Message-ID: <1707958.iSX8Mzt5vJ@x2> References: <20180615124523.5474-1-omosnace@redhat.com> <6256309.PHt7FQ3KpR@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Ondrej Mosnacek Cc: Richard Guy Briggs , Linux-Audit Mailing List List-Id: linux-audit@redhat.com On Tuesday, June 19, 2018 4:57:37 AM EDT Ondrej Mosnacek wrote: > 2018-06-18 20:39 GMT+02:00 Steve Grubb : > > On Friday, June 15, 2018 8:45:22 AM EDT Ondrej Mosnacek wrote: > >> This patch adds a new function that shall be used to log any > >> modification of the system's clock (via the adjtimex() syscall). > >> > >> The function logs an audit record of type AUDIT_TIME_ADJUSTED with the > >> following fields: > >> * txmodes (the 'modes' field of struct timex) > >> * txoffset (the 'offset' field of struct timex) > >> * txfreq (the 'freq' field of struct timex) > >> * txmaxerr (the 'maxerror' field of struct timex) > >> * txesterr (the 'esterror' field of struct timex) > >> * txstatus (the 'status' field of struct timex) > >> * txconst (the 'constant' field of struct timex) > >> * txsec, txusec (the 'tv_sec' and 'tv_usec' fields of the 'time' field > >> of struct timex (respectively)) > >> * txtick (the 'tick' field of struct timex) > > > > Are all of these fields security relevant? Primarily what we need to know > > is if time is being adjusted. This is relevant because a bad guy may > > adjust system time to make something appear to happen earlier or later > > than it really did which make correlation hard or impossible. > > This is still an open question for me... On the one hand, we might > want to know exactly what the bad guy was trying to do ("He changed > the offset to 500 ms." vs. just "He adjusted the clock."), on the > other hand, we may not really care and consider it yet another junk > data in the logs... A possible compromise could be to log only > relevant fields (see 'Possible improvements' in the commit message). > Assuming ntpd or other authorized applications would only modify > one/few variables at a time, this would add only a few fields to the > record each time. I think we want the modes field so that we know what was changed. But do we really need to know maxerror or status? I think we should limit this to the modes and any value of a time adjustment. > Note that this new auxiliary record gets only logged on *modifying* > operations, which should not be that frequent, and thus it shouldn't > be a problem to output a bit of potentially useful information. We're after just security information. > That said, I don't mind logging just an empty record if that is > preferred. An empty buffer doesn't tell us what was adjusted. Thanks, -Steve