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]
Message-ID: <CAHC9VhTZkrmgt7rxNYWTgYvm+TVGgRD6iFu9dDtZ7eYNXBKqHQ@mail.gmail.com>
Date:   Thu, 13 Sep 2018 23:18:56 -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, Aug 24, 2018 at 8:00 AM Ondrej Mosnacek <omosnace@...hat.com> wrote:
> This patch adds two auxiliary record types that will be used to annotate
> the adjtimex SYSCALL records with the NTP/timekeeping values that have
> been changed.
>
> Next, it adds two functions to the audit interface:
>  - audit_tk_injoffset(), which will be called whenever a timekeeping
>    offset is injected by a syscall from userspace,
>  - audit_ntp_adjust(), which will be called whenever an NTP internal
>    variable is changed by a syscall from userspace.
>
> Quick reference for the fields of the new records:
>     AUDIT_TIME_INJOFFSET
>         sec - the 'seconds' part of the offset
>         nsec - the 'nanoseconds' part of the offset
>     AUDIT_TIME_ADJNTPVAL
>         op - which value was adjusted:
>             offset - corresponding to the time_offset variable
>             freq   - corresponding to the time_freq variable
>             status - corresponding to the time_status variable
>             adjust - corresponding to the time_adjust variable
>             tick   - corresponding to the tick_usec variable
>             tai    - corresponding to the timekeeping's TAI offset

I understand that reusing "op" is tempting, but the above aren't
really operations, they are state variables which are being changed.
Using the CONFIG_CHANGE record as a basis, I wonder if we are better
off with something like the following:

 type=TIME_CHANGE <var>=<value_new> old=<value_old>

... you might need to preface the variable names with something like
"ntp_" or "offset_".  You'll notice I'm also suggesting we use a
single record type here; is there any reason why two records types are
required?

>         old - the old value
>         new - the new value
>
> Signed-off-by: Ondrej Mosnacek <omosnace@...hat.com>
> ---
>  include/linux/audit.h      | 21 +++++++++++++++++++++
>  include/uapi/linux/audit.h |  2 ++
>  kernel/auditsc.c           | 15 +++++++++++++++
>  3 files changed, 38 insertions(+)

A reminder that we need tests for these new records and a RFE page on the wiki:

* https://github.com/linux-audit/audit-testsuite
* https://github.com/linux-audit/audit-kernel/wiki

-- 
paul moore
www.paul-moore.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ