Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4048258imm; Mon, 17 Sep 2018 07:25:59 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZ6axp+ZZKl+7CnbUFjbADxHDFkIwEMzFOAJgchdbodEd3kVcyLeeD7xJw32C4XaOMLFa3N X-Received: by 2002:a17:902:4d45:: with SMTP id o5-v6mr25195172plh.78.1537194359073; Mon, 17 Sep 2018 07:25:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537194359; cv=none; d=google.com; s=arc-20160816; b=ZpaxmVtlUlOiCNeEI/qmOWrQD4vaXCJkUy7KvgOKcT4E330UsniwkS/PDUz/SlEPNY EfRXgQgL67fXwm5OFTIKVYMoiFuOKCWQGn5W2cq/PJcWLd+vsmsXL9tF97Q6N/qmIKw7 m8JYFHovay7V6ufUQhGo0CSgCbbw6WzGkNq7XSab1ZENNmEilO6WcitzJ7zz/iXMfyiN TXaPWMCHo2rcEA44VXuyE8nf73rYgNKzIN4nzLGQl77ZVQedHKYJnZMj/7HDDmqVCFOK 51CwQqJ/AO9AGeCg3Y/MdRV3Isd6hr4KbFhhnEn/hdlbjy2JaeEebOERH1M595LuTnz4 VKAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+vFmya8upAGq2tasnUAfnRZMVI9w7fiFzC7W/gtsn4E=; b=JW56XweUPVOh4o5Q5sEFqr0XH9y8ZJvjvqTZSsauMh/IbAYMAOk5VrNQskdlPWul3h PnczCDMrX36Tk9ZOGGAIEi/5QrSu6g9ThgPcug0qTKDSx+Ya2SsuasFfFXjKo72yrSFK PzMxzrQ530OwbM6Cmc+tDMYFTXY/OW9NO9ESydLmT6AhkPBcBTdkKW4MErHDVSAqo0WK beeFB59zm0fq70I1GhG16cVJ+f51QeNLJUiOO+uruVpVQP0n+2SVJGcL4OYDH4pOjI9S phlqJ3LyHCQ4iv7T8rVGJ3vJcV8PHFoFc5/JUTybqmGmMZaVMxLg17M8JTraursPcCAi bvoQ== 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 v2-v6si16713267pfv.57.2018.09.17.07.25.40; Mon, 17 Sep 2018 07:25:59 -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 S1728808AbeIQTwb (ORCPT + 99 others); Mon, 17 Sep 2018 15:52:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33640 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728065AbeIQTwb (ORCPT ); Mon, 17 Sep 2018 15:52:31 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9C065811A9; Mon, 17 Sep 2018 14:24:57 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-40.phx2.redhat.com [10.3.112.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 03D0078C1D; Mon, 17 Sep 2018 14:24:49 +0000 (UTC) Date: Mon, 17 Sep 2018 10:20:00 -0400 From: Richard Guy Briggs To: Ondrej Mosnacek Cc: Paul Moore , Linux-Audit Mailing List , Steve Grubb , Miroslav Lichvar , John Stultz , Thomas Gleixner , Stephen Boyd , Linux kernel mailing list Subject: Re: [PATCH ghak10 v5 1/2] audit: Add functions to log time adjustments Message-ID: <20180917142000.akpg7ul4jufujo4o@madcap2.tricolour.ca> References: <20180824120001.20771-1-omosnace@redhat.com> <20180824120001.20771-2-omosnace@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180512 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 17 Sep 2018 14:24:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-09-17 14:38, Ondrej Mosnacek wrote: > On Fri, Sep 14, 2018 at 5:19 AM 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. > > I remember Steve (or was it Richard?) convincing me at one of the > meetings that "op" is the right filed name to use, despite it not > being a name for an operation... But I don't really care, I'm okay > with changing it to e.g. "var" as Richard suggests later in this > thread. > > > 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? > > There are actually two reasons: > 1. The injected offset is a timespec64, so it consists of two integer > values (and it would be weird to produce two records for it, since IMO > it is conceptually still a single variable). > 2. In all other cases the variable is reset to the (possibly > transformed) input value, while in this case the input value is added > directly to the system time. This can be viewed as a kind of variable > too, but it would be weird to report old and new value for it, since > its value flows with time. > > Plus, when I look at: > type=TIME_INJOFFSET [...]: sec=-16 nsec=124887145 > > I can immediately see that the time was shifted back by 16-something > seconds, while when I look at something like: > > type=TIME_CHANGE [...]: var=time_sec new=1537185685 old=1537185701 > type=TIME_CHANGE [...]: var=time_nsec new=664373417 old=789260562 > > I can just see some big numbers that I need to do math with before I > get an idea of what is the magnitude (or sign) of the change. > > > > 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 > > I was going to start working on this once the format issues are > settled. (Although I probably should have kept the RFC in the subject > until then...) There are more iterative development methods (to which we appear to be trying to steer) where the test is written first, partly helping clarify what the goal is. Refining the test is incremental. > > * https://github.com/linux-audit/audit-kernel/wiki > > I admit I forgot about this duty, but again I would like to wait for > the discussions to settle before writing that up. While tempting to leave it to the end, documenting it initially can help clarify in your own mind what you are trying to accomplish and can help others understand what you are trying to do. > > paul moore > Ondrej Mosnacek - 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