Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp42174img; Wed, 27 Mar 2019 16:29:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqxU7CY6zO3wSs4kyKL2yuhTCQyyi1QFqQ0VZT6K2nRz1SRZPg47oxcSZh6XUvtozlIRdOu7 X-Received: by 2002:a63:6fcf:: with SMTP id k198mr24546595pgc.158.1553729349917; Wed, 27 Mar 2019 16:29:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553729349; cv=none; d=google.com; s=arc-20160816; b=DCfHLjqWmZsmsIF0jCvgl9xyA2wmX8Mr66lAV1g1xfUHBkodvqZw4RvUJyKR/4NdnW 2WTxRwA7+WWgzpkW/CbPAxlmtSo6qkwgKy/ocNwXFfyeLpQY7fzbAQUwIYWwwF7nNhG+ 3tRacyFsG7SXH6XurDpZuP1NdCUe+pvEnrtKyuBPCzEhGBetoC/55AoGa7FzRA2/h5Qd eaGgXtfGskdD21H4UbeEQOooZNCRSBlUA9u6yRyEp3oZQkBGtMCJtSpQy+XmJZfgg/MN 6Oahhy/VjLJ2y8UKWwhUyny6Z3KKI2UVyjA/96R9HuAzmd0A3CEet1+Ovo3XCvTdtVyp 2bCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=8Lt5TVh5MU0d2cp8puyfpebNIyB3NvyiWzTqut/fJ9I=; b=NOEDDhTWpPKoiO7teLnDhzmtXHHWP6o3n1Lj2vsQW+H3GBOwR0mAbn0y/hwx63fakW X/Yy0N6iwqkA0hEEaKvSAKPujmINMaVTROHgdf2tTBxPkTkER8y8rNiGhvi/9me8umq8 xSxDG9kGjygJ7y7xdoP+h2VFaLY7STrX+NEOq+VBYaD/lZHCyn76kLX1uXtcxx+DohTN 6XA2bQEuxz+H9+YjyubPqA07h4jhIvc2yenEW+EYCB2Ml0et21v79gzWVMdIdRHDJVbM BL11e9i1ZX8y0j+b99SCeZST6fup3txDmV0vVuqUKt94LsFJHc5ZhmENgtsNlqEjXovi 04Mw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BQYOyZFW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q63si19993883pfb.154.2019.03.27.16.28.52; Wed, 27 Mar 2019 16:29:09 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BQYOyZFW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728457AbfC0X1N (ORCPT + 99 others); Wed, 27 Mar 2019 19:27:13 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:41669 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726055AbfC0X1N (ORCPT ); Wed, 27 Mar 2019 19:27:13 -0400 Received: by mail-wr1-f66.google.com with SMTP id r4so12890151wrq.8 for ; Wed, 27 Mar 2019 16:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8Lt5TVh5MU0d2cp8puyfpebNIyB3NvyiWzTqut/fJ9I=; b=BQYOyZFWS2ESn0GzsZHeiNYTWdgeGa7idQbBBzduH538wb3FEdmjDFdD47hww2r+aM rwbhtlaAUT4mex3fKn0FDMht8QXg3gLq1fLA5VmuqCx+aKk+CHpYut6swC1PaY10Ojjc QhRCMNlmweMHfKfo1O1KzvVM7qQc4GG0qFF+SWVHbzl/u4bz27xr2fkdBYjv7M6Rdi9P rRbq3zlkn+Y9pJ/6EDDdE3c5HdoMs0a5su1sxzpaUHPeH4q/IvuK1N58HaT5iQl421fh J2UTEEZpSgLYBM93nUPTVYOyTWWpOaUoowi+ZIrq5e7NLgH5Uf3u0uWwHWuN/3AxoFs9 DQJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8Lt5TVh5MU0d2cp8puyfpebNIyB3NvyiWzTqut/fJ9I=; b=IxsJkftNSqUvRormYfpPjtGJPsFIxW88g3BfXz8XJZAiMV3Qd/VgaClT3mFf2Tjzfy B8NY320boLE28CFhYpK/o5sFsrSnUJUUI5isTAqIOZu0fZTIHemhZj2ALA0YMK7JpVrh f4kARMZMDUDUWYYfUutnjANFhqmgs04/RReul+ObLhdVZNRgjsF0BNkKFKntVa2SGZPk xu1E8v9RFXh7gVDLPxnib+RFHZ1sTrUDArexI6E8m5UEPs43+4nyvtyj5uBUCXb0dWUq D9TyH/n5FjKQXcTIXdTA0bqmdjimdBvkbbuL5AoimoWwlCYPe41SIZbQy+PPxwES2+gH dTog== X-Gm-Message-State: APjAAAXa0Yf4zKKUWEvFJGyiSk8p+5RBafYqdLXhft9upYmhqYgfbPht JCPT9J8piIrkpJAP0ZdcbxLYldMK2XQW/B5FPY2GbfKi5xM= X-Received: by 2002:a5d:6050:: with SMTP id j16mr25530523wrt.253.1553729230185; Wed, 27 Mar 2019 16:27:10 -0700 (PDT) MIME-Version: 1.0 References: <20190307123254.348-1-omosnace@redhat.com> <20190307123254.348-2-omosnace@redhat.com> In-Reply-To: <20190307123254.348-2-omosnace@redhat.com> From: John Stultz Date: Wed, 27 Mar 2019 16:26:57 -0700 Message-ID: Subject: Re: [RFC PATCH ghak10 v6 1/2] timekeeping: Audit clock adjustments To: Ondrej Mosnacek Cc: linux-audit@redhat.com, Paul Moore , Richard Guy Briggs , Steve Grubb , Miroslav Lichvar , Thomas Gleixner , Stephen Boyd , lkml Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 7, 2019 at 4:33 AM Ondrej Mosnacek wrote: > > Emit an audit record whenever the system clock is changed (i.e. shifted > by a non-zero offset) by a syscall from userspace. The syscalls than can > (at the time of writing) trigger such record are: > - settimeofday(2), stime(2), clock_settime(2) -- via > do_settimeofday64() > - adjtimex(2), clock_adjtime(2) -- via do_adjtimex() > > The new records have type AUDIT_TIME_INJOFFSET and contain the following > fields: > - sec -- the 'seconds' part of the offset > - nsec -- the 'nanoseconds' part of the offset > > For reference, running the following commands: > > auditctl -D > auditctl -a exit,always -F arch=3Db64 -S adjtimex > chronyd -q > > triggers (among others) a syscall that produces audit records like this: > > type=3DTIME_INJOFFSET msg=3Daudit(1530616049.652:13): sec=3D-16 nsec=3D12= 4887145 > type=3DSYSCALL msg=3Daudit(1530616049.652:13): arch=3Dc000003e syscall=3D= 159 success=3Dyes exit=3D5 a0=3D7fff57e78270 a1=3D1 a2=3Dfffffffffffffff0 a= 3=3D137b828205ca12 items=3D0 ppid=3D626 pid=3D629 auid=3D0 uid=3D385 gid=3D= 382 euid=3D385 suid=3D385 fsuid=3D385 egid=3D382 sgid=3D382 fsgid=3D382 tty= =3D(none) ses=3D1 comm=3D"chronyd" exe=3D"/usr/sbin/chronyd" subj=3Dsystem_= u:system_r:kernel_t:s0 key=3D(null) > type=3DPROCTITLE msg=3Daudit(1530616049.652:13): proctitle=3D6368726F6E79= 64002D71 cd /home/omosnace/Dokumenty/Kernel/worktrees/audit/src/kernel/time > s Hrm. Ugly log spam aside (I get it sort of goes with the territory :), I could imagine someone looking at this and wanting to also know when the injection was applied. Obviously the whole point of the offset injection is we don't really care about the when, we only want a fixed offset to be made atomically. That said, if someone did try to add such a timestamp on the log, there's the problem of trying to calculate the time while holding the timekeeping locks. So, are you certain the next request won't be to try to to also calculate a timestamp and push it into the audit_log() call as well? Also, we have to be careful with anything we call from the timekeeping code, its really easy for some corner case to trip something that then tries to read the time and we deadlock, particularly with rare cases like time adjustments. I'm not familiar with the audit subsystem, but from a maintenance point of view, can we make sure there's enough documentation so that audit_log() and everything it calls will never in the future call back into the timekeeping code? I suspect this is already covered, so apologies for the boilerplate concern, but I want to be sure. > The above records have been produced by the following syscall from > chronyd (as per strace output): > > adjtimex({modes=3DADJ_SETOFFSET|ADJ_NANO, offset=3D0, freq=3D750433, maxe= rror=3D16000000, esterror=3D16000000, status=3DSTA_UNSYNC|STA_NANO, constan= t=3D2, precision=3D1, tolerance=3D32768000, time=3D{tv_sec=3D1530616033, tv= _usec=3D778717675}, tick=3D10000, ppsfreq=3D0, jitter=3D0, shift=3D0, stabi= l=3D0, jitcnt=3D0, calcnt=3D0, errcnt=3D0, stbcnt=3D0, tai=3D0}) =3D 5 (TIM= E_ERROR) > > (The struct timex fields above are from *after* the syscall was > executed, so they contain the current (new) values as set from the > kernel, except of the 'modes' field, which contains the original value > sent by the caller.) > > Signed-off-by: Ondrej Mosnacek > --- > include/linux/audit.h | 15 +++++++++++++++ > include/uapi/linux/audit.h | 1 + > kernel/auditsc.c | 8 ++++++++ > kernel/time/timekeeping.c | 6 ++++++ > 4 files changed, 30 insertions(+) > > diff --git a/include/linux/audit.h b/include/linux/audit.h > index 1e69d9fe16da..43a60fbe74be 100644 > --- a/include/linux/audit.h > +++ b/include/linux/audit.h > @@ -27,6 +27,7 @@ > #include > #include /* LOOKUP_* */ > #include > +#include > > #define AUDIT_INO_UNSET ((unsigned long)-1) > #define AUDIT_DEV_UNSET ((dev_t)-1) > @@ -365,6 +366,7 @@ extern void __audit_log_capset(const struct cred *new= , const struct cred *old); > extern void __audit_mmap_fd(int fd, int flags); > extern void __audit_log_kern_module(char *name); > extern void __audit_fanotify(unsigned int response); > +extern void __audit_tk_injoffset(struct timespec64 offset); > > static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp) > { > @@ -467,6 +469,16 @@ static inline void audit_fanotify(unsigned int respo= nse) > __audit_fanotify(response); > } > > +static inline void audit_tk_injoffset(struct timespec64 offset) > +{ > + /* ignore no-op events */ > + if (offset.tv_sec =3D=3D 0 && offset.tv_nsec =3D=3D 0) > + return; > + > + if (!audit_dummy_context()) > + __audit_tk_injoffset(offset); > +} > + > extern int audit_n_rules; > extern int audit_signals; > #else /* CONFIG_AUDITSYSCALL */ > @@ -580,6 +592,9 @@ static inline void audit_log_kern_module(char *name) > static inline void audit_fanotify(unsigned int response) > { } > > +static inline void audit_tk_injoffset(struct timespec64 offset) > +{ } > + > static inline void audit_ptrace(struct task_struct *t) > { } > #define audit_n_rules 0 > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h > index 36a7e3f18e69..2167d55bc800 100644 > --- a/include/uapi/linux/audit.h > +++ b/include/uapi/linux/audit.h > @@ -114,6 +114,7 @@ > #define AUDIT_REPLACE 1329 /* Replace auditd if this packet = unanswerd */ > #define AUDIT_KERN_MODULE 1330 /* Kernel Module events */ > #define AUDIT_FANOTIFY 1331 /* Fanotify access decision */ > +#define AUDIT_TIME_INJOFFSET 1332 /* Timekeeping offset injected */ > > #define AUDIT_AVC 1400 /* SE Linux avc denial or grant *= / > #define AUDIT_SELINUX_ERR 1401 /* Internal SE Linux Errors */ > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index d1eab1d4a930..781336d0f2de 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -2512,6 +2512,14 @@ void __audit_fanotify(unsigned int response) > AUDIT_FANOTIFY, "resp=3D%u", response); > } > > +/* We need to allocate with GFP_ATOMIC here, since these two functions w= ill be > + * called while holding the timekeeping lock: */ > +void __audit_tk_injoffset(struct timespec64 offset) > +{ > + audit_log(audit_context(), GFP_ATOMIC, AUDIT_TIME_INJOFFSET, > + "sec=3D%lli nsec=3D%li", (long long)offset.tv_sec, offs= et.tv_nsec); > +} > + > static void audit_log_task(struct audit_buffer *ab) > { > kuid_t auid, uid; > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > index ac5dbf2cd4a2..0f0b566afe61 100644 > --- a/kernel/time/timekeeping.c > +++ b/kernel/time/timekeeping.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > > #include "tick-internal.h" > #include "ntp_internal.h" > @@ -1250,6 +1251,9 @@ out: > /* signal hrtimers about time change */ > clock_was_set(); > > + if (!ret) > + audit_tk_injoffset(ts_delta); > + > return ret; > } > EXPORT_SYMBOL(do_settimeofday64); > @@ -2322,6 +2326,8 @@ int do_adjtimex(struct timex *txc) > ret =3D timekeeping_inject_offset(&delta); > if (ret) > return ret; > + > + audit_tk_injoffset(delta); > } > > ktime_get_real_ts64(&ts); Ignoring my worry above, from a quick read over, the code here looks ok to me. Though I've not actually applied and tinkered with it. Acked-by: John Stultz