lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ