linux-kernel - Re: [PATCH ghak10 v5 1/2] audit: Add functions to log time adjustments

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] [day] [month] [year] [list]

Date:   Sat, 22 Sep 2018 16:42:35 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     omosnace@...hat.com
Cc:     linux-audit@...hat.com, rgb@...hat.com, sgrubb@...hat.com,
        mlichvar@...hat.com, john.stultz@...aro.org, tglx@...utronix.de,
        sboyd@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH ghak10 v5 1/2] audit: Add functions to log time adjustments

On Fri, Sep 21, 2018 at 7:21 AM Ondrej Mosnacek <omosnace@...hat.com> wrote:
> On Mon, Sep 17, 2018 at 4:51 PM Paul Moore <paul@...l-moore.com> wrote:
> > On Mon, Sep 17, 2018 at 8:38 AM Ondrej Mosnacek <omosnace@...hat.com> wrote:
> > > On Fri, Sep 14, 2018 at 5:19 AM Paul Moore <paul@...l-moore.com> wrote:
> > > > On Fri, Aug 24, 2018 at 8:00 AM Ondrej Mosnacek <omosnace@...hat.com> wrote:

...

> > Okay, with that in mind, perhaps when recording the offset values we
> > omit the "old" values (arguably that doesn't make much sense here) and
> > keep the sec/nsec split:
> >
> > type=TIME_CHANGE [...]: offset_sec=<X> offset_nsec=<Y>
> >
> > ... and for all others we stick with:
> >
> > type=TIME_CHANGE [...]: ntp_<VAR>=<NEWVAL> old=<OLD_VAL>
>
> Alright, that format would work. However, I would still like to have a
> separate type for the offset injection, since it has different field
> structure and semantics (difference vs. new+old). I don't see any
> reason to sacrifice the distinction for just one record type slot
> (AFAIK we technically still have about 2 billion left...).
>
> (Maybe you just duplicated the record type by mistake, in that case
> please disregard the last sentence.)

A reasonable guess on the typo, but no that was intentional :)

As described above, there is no set field ordering for the TIME_CHANGE
record, just like there is not set field ordering for the
CONFIG_CHANGE record.  Why?  We only include the state variables that
are being changed instead of including all of the available state
variables.  Yes, historically there are the "new" and "old" fields,
but I don't see that as a strong convention; the special "old=" field
name helps prevent confusion.

Yes, we aren't really at risk of running out of record types, but why
do we *need* two types here?  I don't believe the ordering/structure
argument is significant in this particular case, and I would much
rather see all the time related state changes included in one
TIME_CHANGE record.

-- 
paul moore
www.paul-moore.com