ut 19. 6. 2018 o 22:52 Steve Grubb <[email protected]> napísal(a): > On Tuesday, June 19, 2018 4:57:37 AM EDT Ondrej Mosnacek wrote: > > 2018-06-18 20:39 GMT+02:00 Steve Grubb <[email protected]>: > > > 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.
Well, the status field can be at the very least used to set the STA_INS/STA_DEL status flags [1], which seem to coordinate the insertion of leap second. Now this may be a bit far-fetched, but I can imagine how bogus insertions of leap seconds could be used to gradually shift the clock to a bad value. I think we can safely drop maxerror/esterror (I believe these are just informational of how much the clock is 'out of sync'), but the rest seems like it could at least indirectly influence the time (IOW, I wasn't able to find a proof that it can't...). [1] https://elixir.bootlin.com/linux/v4.17/source/include/uapi/linux/timex.h#L128 > > > 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. Yes, sorry, that should have been "a record with only modes field". > > Thanks, > -Steve > >-- Ondrej Mosnacek <omosnace at redhat dot com> Associate Software Engineer, Security Technologies Red Hat, Inc. -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
