Messages in this thread | | | Date | Mon, 20 Aug 2018 17:21:57 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [RFC PATCH ghak10 v4 0/2] audit: Log modifying adjtimex(2) calls |
| |
On Mon, 20 Aug 2018, Ondrej Mosnacek wrote:
+ Miroslav Lichvar
> Hi, > > this patchset implements more detailed auditing of the adjtimex(2) > syscall in order to make it possible to: > a) distinguish modifying vs. read-only calls in the audit log > b) reconstruct from the audit log what changes were made and how they > have influenced the system clock > > The main motivation is to be able to detect an adversary that tries to > confuse the audit timestamps by changing system time via adjtimex(2), > but at the same time avoid flooding the audit log with records of benign > read-only adjtimex(2) calls. > > @John or other timekeeping/NTP folks: We had a discussion on the audit > ML on which of the internal timekeeping/NTP variables we should actually > log changes for. We are only interested in variables that can (directly > or indirectly) cause noticeable changes to the system clock, but since we > have only limited understanding of the NTP code, we would like to ask > you for advice on which variables are security relevant. > > Right now, the patchset is conservative and logs all changes that can be > done via adjtimex(2): > - direct injection of timekeeping offset (obviously relevant) > - adjustment of timekeeping's TAI offset > - NTP value adjustments: > - time_offset (probably important) > - time_freq (maybe not important?) > - time_status (likely important, can cause leap second injection) > - time_maxerror (maybe not important?) > - time_esterror (maybe not important?) > - time_constant (???) > - time_adjust (sounds important) > - tick_usec (???) > > Could you please give us some hints on the effect of changing these > variables and whether you think that it is important to log their > changes? > > Thanks a lot! > > > GitHub issue: https://github.com/linux-audit/audit-kernel/issues/10 > > Changes in v4: > - Squashed first two patches into one > - Rename ADJNTPVAL's "type" field to "op" to align with audit record > conventions > - Minor commit message editing > - Cc timekeeping/NTP people for feedback > > v3: https://www.redhat.com/archives/linux-audit/2018-July/msg00001.html > Changes in v3: > - Switched to separate records for each variable > - Both old and new value is now reported for each change > - Injecting offset is reported via a separate record (since this > offset consists of two values and is added directly to the clock, > i.e. it doesn't make sense to log old and new value) > - Added example records produced by chronyd -q (see the commit message > of the last patch) > > v2: https://www.redhat.com/archives/linux-audit/2018-June/msg00114.html > Changes in v2: > - The audit_adjtime() function has been modified to only log those > fields that contain values that are actually used, resulting in more > compact records. > - The audit_adjtime() call has been moved to do_adjtimex() in > timekeeping.c > - Added an additional patch (for review) that simplifies the detection > if the syscall is read-only. > > v1: https://www.redhat.com/archives/linux-audit/2018-June/msg00095.html > > Ondrej Mosnacek (2): > audit: Add functions to log time adjustments > timekeeping/ntp: Audit clock/NTP params adjustments > > include/linux/audit.h | 21 ++++++++++++++++ > include/uapi/linux/audit.h | 2 ++ > kernel/auditsc.c | 15 ++++++++++++ > kernel/time/ntp.c | 50 ++++++++++++++++++++++++++++++-------- > kernel/time/timekeeping.c | 3 +++ > 5 files changed, 81 insertions(+), 10 deletions(-) > > -- > 2.17.1 > >
| |