Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3923208imm; Mon, 17 Sep 2018 05:33:29 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZzb/+WKO4TsUVqHhmI1ibf/HT7kRo26V2+lTPycHY74oMVYHtSGkq9OfI0I099W0v4f5sq X-Received: by 2002:a17:902:47c2:: with SMTP id d2-v6mr24989980plh.317.1537187608969; Mon, 17 Sep 2018 05:33:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537187608; cv=none; d=google.com; s=arc-20160816; b=f/UCL/3O8y07yeVlLm0xxDOx+ZCUr7mdK/G+HC0hl3mIYDCbhSNp84BXfcf6bOdale gB1SxthWUfrw2Lp1Z3xazC5nD2oPgC0Ol06VyeBT7AfMSw82o3HE87+lfonTmFmgKeBo liC5XHTaM4V0gPDJA6CFtICL1LSl+QrdiJjMuAr3oB+N++K/D52lkLimkroeSw4bXywN k0jjEbfMRtxjg6bMDP4pmqk1FZqKqxwOwnFgDj3evTTDAvQmMt5Z9Q1JicrvwZt0V3ml bka3CYobr+7bMHc6mTEX9CqXYqM21uE0F6W0Cb5Xuf+FMEv/rKr2k3QwirI96hcfosGx ytlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=e5aHiR6+3zt3C7Vzzfckl9vUMf6yvzMEKWhn7kTjaL8=; b=FuR36z6+Gtoh1E3ot8U+nZ7t/aNg19lhduRaqmQtYizy+q7uXnHH6chgzlqrcVkRfC 5In9KOS+GUydIU3K+hO8bmBQpo8xV2S0AgrMplpfIJLTn6Cc9pA6VfbySn1dFdR381em tzdzCKp7/qm0tHhuu3rFDx+1QxSGLhQNODrSR2dJzISWB9UFkboueE2FlC296kVn5Tt/ JVNYTsxZMp0G3erWAM1/YOLe3r8cJCrjVt4Y8DYVP4GAahK2i2YRNGtwuFLu/Gyr1cyB HM5V3sgIwCTTYEFQ90qf5Ol3TUJK7nJyemmxWeFg7BfBBxwKulIttAE1q5i03roUKhAe dgLQ== 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 w1-v6si16896639pff.1.2018.09.17.05.33.05; Mon, 17 Sep 2018 05:33:28 -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 S1728496AbeIQSAG (ORCPT + 99 others); Mon, 17 Sep 2018 14:00:06 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:41854 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728134AbeIQSAF (ORCPT ); Mon, 17 Sep 2018 14:00:05 -0400 Received: by mail-oi0-f66.google.com with SMTP id k12-v6so18710313oiw.8 for ; Mon, 17 Sep 2018 05:32:58 -0700 (PDT) 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; bh=e5aHiR6+3zt3C7Vzzfckl9vUMf6yvzMEKWhn7kTjaL8=; b=oVD2Vu1yOwSACaHBJ8S0WaPCxLXalTOatKRlYPcVwRFkM0arhxppoahGasUQ78SRAG sjNVWjYw07Tlq+LHABgjttEgOlI145XZgOQNw4MHDmMh9dGbMrESyHzZF/6MxqDQF77p 0/Y96aiEreKxGWIO2SVIaZpgKN17whF1aahgrWFlrD7R7BL8mW4uuP7OsVRllPHf7Sv3 yX1ryYljGeUUGmP6L/BkfO+VCWiLQDegfGofi4urWmCfFoum16K7fr6cx6gLZCa64shC LtKGizS3Fs/1enWHwN/74yWOK7dR4qC0G0UWwb4PRFlmTnWfJwjvBppNHqmz1RBHyatj pgaw== X-Gm-Message-State: APzg51CdNLGFXLeYSdg7I3hb5LE2w8WXrAlYH8KDAEl9kXwaB8b6YxL5 lGyOKGg6v3HpnwMuLWwEerxWHXtHnTcGu3VnvrjLyQ== X-Received: by 2002:aca:6044:: with SMTP id u65-v6mr17526928oib.323.1537187577929; Mon, 17 Sep 2018 05:32:57 -0700 (PDT) MIME-Version: 1.0 References: <20180824120001.20771-1-omosnace@redhat.com> <20180827075020.GL27091@localhost> <4819575.TSNxuEWROA@x2> <20180913151455.yxvtcorxakh7vqrq@madcap2.tricolour.ca> In-Reply-To: <20180913151455.yxvtcorxakh7vqrq@madcap2.tricolour.ca> From: Ondrej Mosnacek Date: Mon, 17 Sep 2018 14:32:46 +0200 Message-ID: Subject: Re: [PATCH ghak10 v5 1/2] audit: Add functions to log time adjustments To: Richard Guy Briggs Cc: Steve Grubb , Miroslav Lichvar , Linux-Audit Mailing List , Paul Moore , John Stultz , Thomas Gleixner , Stephen Boyd , Linux kernel mailing list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 13, 2018 at 5:19 PM Richard Guy Briggs wrote: > On 2018-09-13 15:59, Ondrej Mosnacek wrote: > > On Mon, Aug 27, 2018 at 6:38 PM Steve Grubb wrote: > > > On Monday, August 27, 2018 5:13:17 AM EDT Ondrej Mosnacek wrote: > > > > On Mon, Aug 27, 2018 at 9:50 AM Miroslav Lichvar > > > wrote: > > > > > On Fri, Aug 24, 2018 at 02:00:00PM +0200, 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. > > > > > > > > > > It seems the "adjust" function intentionally logs also calls/modes > > > > > that don't actually change anything. Can you please explain it a bit > > > > > in the message? > > > > > > > > > > NTP/PTP daemons typically don't read the adjtimex values in a normal > > > > > operation and overwrite them on each update, even if they don't > > > > > change. If the audit function checked that oldval != newval, the > > > > > number of messages would be reduced and it might be easier to follow. > > > > > > > > We actually want to log any attempt to change a value, as even an > > > > intention to set/change something could be a hint that the process is > > > > trying to do something bad (see discussion at [1]). > > > > > > One of the problems is that these applications can flood the logs very > > > quickly. An attempt to change is not needed unless it fails for permissions > > > reasons. So, limiting to actual changes is probably a good thing. > > > > Well, Richard seemed to "violently" agree with the opposite, so now I > > don't know which way to go... Paul, you are the official tie-breaker > > here, which do you prefer? > > The circumstances have changed with new information being added. I > recall violently agreeing several iterations ago with your previous > assessment, which has also changed with this new information. I'd agree > with Steve that a flood of information about something that did not > change value could hide important information. OK, understood. > (BTW: The expression "to violoently agree with" is generally used in a > situation where two parties appear to have been arguing two different > sides of an issue and then realize they have much more in common than > initially apparent.) I see, thanks for the explanation! I didn't know that expression before, so I think I took it a bit too literally :) > > > > -Steve > > > > > > > There are valid > > > > arguments both for and against this choice, but we have to pick one in > > > > the end... Anyway, I should explain the reasoning in the commit > > > > message better, right now it just states the fact without explanation > > > > (in the second patch), thank you for pointing my attention to it. > > > > > > > > [1] https://www.redhat.com/archives/linux-audit/2018-July/msg00061.html > > > > > > > > -- > > > > Ondrej Mosnacek > > > > 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 -- Ondrej Mosnacek Associate Software Engineer, Security Technologies Red Hat, Inc.