Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp938756imm; Fri, 14 Sep 2018 08:34:31 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdad5qjsmyS6wsaF1jKrUMlw0cGYU5YpEIBxMygVL5TzEqA9wiHbMzj2V9WvtiIixKpbBEoM X-Received: by 2002:a62:7885:: with SMTP id t127-v6mr13216413pfc.6.1536939271779; Fri, 14 Sep 2018 08:34:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536939271; cv=none; d=google.com; s=arc-20160816; b=YPoB+0CvpTT6xdWKVLF9v1x6eN4Aaj8IojXOCao1xuAd3rw0J2NX5nZp6A5f0Nj8+l Wi9qriSVhq0p02ha3Nzg8bKD1txXyc5BERkdc6landv302C3gto79wR/K823lLT5NIbh 2fEAYmyGza6Yh3nJlLao/hmR3JGjlhiiasqT5VMifLY/WYLegYt6DO8OlKEUL60GQYrY DbwryToesyXq99aPJdojuwqVU9ecVadMfXkBq8DzJV8gfHV7qmpoZyIp+tWL6KB0uGKL RbmWpG2xKA3TwE6nAprLwglRh/abriMZbPA9QaG0cwa1Bh8jc5Sw/tbzBwETN3q/1RLl 9wxg== 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:mime-version :references:in-reply-to:organization:message-id:date:subject:cc:to :from; bh=xfVoucB+zi3pK+5vHeigZgI08rWNHQCN7t2F6YGCgO4=; b=ff3Td0QJaIjhDoAgBX5WoPnt0GCq9QOJuwITB0oiq/Z/y9hJ5KiALvfSbikjk6ZfEv Bj/ad8TpI1VhW5nTp3nY4m9hCfgdDaehzyYkBvwwBaCt59KhBRgzSrbKvO87oty/s2pI cxV7RjDijeYll+WluEQWRZKEJPvKTk9k3zsnKGRiZbCfKDcxYT5fwhfR9bCRzJtopfjK 0LxIERkjacnZNfzEeVlpFUMAp1sROWZLLzhY4dopmkVOJnOcB3p5Qkw2thYrKyL0Tpo3 fYx/U/KkZD2XWVFdaQ5WGm4WYJfuV4Jl687CqBq9WXeMr5NmN+Q2A6hSOLTw9tMAxVl8 +QHw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v71-v6si6958736pgd.601.2018.09.14.08.34.15; Fri, 14 Sep 2018 08:34:31 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728162AbeINUtJ (ORCPT + 99 others); Fri, 14 Sep 2018 16:49:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41162 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726902AbeINUtJ (ORCPT ); Fri, 14 Sep 2018 16:49:09 -0400 Received: from smtp.corp.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 32D28C05680E; Fri, 14 Sep 2018 15:34:07 +0000 (UTC) Received: from x2.localnet (ovpn-124-50.rdu2.redhat.com [10.10.124.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id DDE319A328; Fri, 14 Sep 2018 15:34:01 +0000 (UTC) From: Steve Grubb To: Richard Guy Briggs Cc: Paul Moore , omosnace@redhat.com, linux-audit@redhat.com, mlichvar@redhat.com, john.stultz@linaro.org, tglx@linutronix.de, sboyd@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH ghak10 v5 1/2] audit: Add functions to log time adjustments Date: Fri, 14 Sep 2018 11:34:00 -0400 Message-ID: <2062051.Ftk13INWii@x2> Organization: Red Hat In-Reply-To: <20180914151643.gwvm5te4nvion5ex@madcap2.tricolour.ca> References: <20180824120001.20771-1-omosnace@redhat.com> <20180914151643.gwvm5te4nvion5ex@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 14 Sep 2018 15:34:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, September 14, 2018 11:16:43 AM EDT Richard Guy Briggs wrote: > On 2018-09-13 23:18, Paul Moore wrote: > > On Fri, Aug 24, 2018 at 8:00 AM Ondrej Mosnacek 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 = 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? > > Why not do something like: > > type=TIME_CHANGE var= new= old= > > So that we don't pollute the field namespace *and* create 8 variants on > the same record format? This shouldn't be much of a concern with binary > record formats, but we're stuck with the current parsing scheme for now. Something like this or the other format is fine. Neither hurt parsing because these are not searchable fields. We only have issues when it involves a searchable field name. HTH... -Steve > > > old - the old value > > > new - the new value > > > > > > Signed-off-by: Ondrej Mosnacek > > > --- > > > > > > 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 > > - RGB > > -- > Richard Guy Briggs > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635