[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFqZXNuodMaEqD6psD375__abLVoe4-q6MrJjM8dT-c3ydcH6g@mail.gmail.com>
Date: Mon, 27 Aug 2018 14:02:06 +0200
From: Ondrej Mosnacek <omosnace@...hat.com>
To: Miroslav Lichvar <mlichvar@...hat.com>
Cc: Richard Guy Briggs <rgb@...hat.com>,
Linux-Audit Mailing List <linux-audit@...hat.com>,
Linux kernel mailing list <linux-kernel@...r.kernel.org>,
Stephen Boyd <sboyd@...nel.org>,
John Stultz <john.stultz@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH ghak10 v5 2/2] timekeeping/ntp: Audit clock/NTP params adjustments
On Mon, Aug 27, 2018 at 1:46 PM Miroslav Lichvar <mlichvar@...hat.com> wrote:
> On Mon, Aug 27, 2018 at 01:35:09PM +0200, Ondrej Mosnacek wrote:
> > On Fri, Aug 24, 2018 at 9:51 PM Richard Guy Briggs <rgb@...hat.com> wrote:
> > > It appears this time_tai use of "constant" is different than
> > > time_constant, the former not mentioned by Miroslav Lichvar. What is it
> > > and is it important to log for security? It sounds like it is
> > > important.
>
> > The TAI offset is the offset of the clock from the International
> > Atomic Time, so basically the time zone offset. I suppose it can't
> > influence the audit timestamps, but changing timezones can still cause
> > all sorts of confusion throughout the system, so intuitively I would
> > say we should log it.
>
> It's not related to timezones. ADJ_TAI sets the offset of the system
> TAI clock (CLOCK_TAI) relative to the standard UTC clock
> (CLOCK_REALTIME). CLOCK_TAI is rarely used by applications. Setting
> the TAI offset effectively injects a whole-second offset to the TAI
> time.
Ah, I stand corrected then. In that case I think we don't actually
need to audit it, since it just changes how the time reported by the
CLOCK_TAI clock type will be different from CLOCK_REALTIME. Playing
with this value could cause some strange jumps in time for
applications that use it, but this seems like a very unlikely
situation. It really depends on how careful we want to be (vs. how
eagerly we want to reduce unimportant records), but this already looks
like logging it would be overdoing it...
Thanks for the correction, I really should RTFM more :)
--
Ondrej Mosnacek <omosnace at redhat dot com>
Associate Software Engineer, Security Technologies
Red Hat, Inc.
Powered by blists - more mailing lists