From: Steve Grubb <sgrubb@redhat.com> To: Ondrej Mosnacek <omosnace@redhat.com> Cc: Miroslav Lichvar <mlichvar@redhat.com>, Linux-Audit Mailing List <linux-audit@redhat.com>, Paul Moore <paul@paul-moore.com>, Richard Guy Briggs <rgb@redhat.com>, John Stultz <john.stultz@linaro.org>, Thomas Gleixner <tglx@linutronix.de>, Stephen Boyd <sboyd@kernel.org>, Linux kernel mailing list <linux-kernel@vger.kernel.org> Subject: Re: [PATCH ghak10 v5 1/2] audit: Add functions to log time adjustments Date: Mon, 27 Aug 2018 12:38:09 -0400 [thread overview] Message-ID: <4819575.TSNxuEWROA@x2> (raw) In-Reply-To: <CAFqZXNvADB-E_fjEaQpUymSVvfP-vXQXtk3K+nJ9DqrScHL8bQ@mail.gmail.com> On Monday, August 27, 2018 5:13:17 AM EDT Ondrej Mosnacek wrote: > On Mon, Aug 27, 2018 at 9:50 AM Miroslav Lichvar <mlichvar@redhat.com> 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. -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 <omosnace at redhat dot com> > Associate Software Engineer, Security Technologies > Red Hat, Inc.
WARNING: multiple messages have this Message-ID (diff)
From: Steve Grubb <sgrubb@redhat.com> To: Ondrej Mosnacek <omosnace@redhat.com> Cc: Richard Guy Briggs <rgb@redhat.com>, Linux kernel mailing list <linux-kernel@vger.kernel.org>, Stephen Boyd <sboyd@kernel.org>, Miroslav Lichvar <mlichvar@redhat.com>, Linux-Audit Mailing List <linux-audit@redhat.com>, John Stultz <john.stultz@linaro.org>, Thomas Gleixner <tglx@linutronix.de> Subject: Re: [PATCH ghak10 v5 1/2] audit: Add functions to log time adjustments Date: Mon, 27 Aug 2018 12:38:09 -0400 [thread overview] Message-ID: <4819575.TSNxuEWROA@x2> (raw) In-Reply-To: <CAFqZXNvADB-E_fjEaQpUymSVvfP-vXQXtk3K+nJ9DqrScHL8bQ@mail.gmail.com> On Monday, August 27, 2018 5:13:17 AM EDT Ondrej Mosnacek wrote: > On Mon, Aug 27, 2018 at 9:50 AM Miroslav Lichvar <mlichvar@redhat.com> 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. -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 <omosnace at redhat dot com> > Associate Software Engineer, Security Technologies > Red Hat, Inc.
next prev parent reply other threads:[~2018-08-27 16:38 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-24 11:59 [PATCH ghak10 v5 0/2] audit: Log modifying adjtimex(2) calls Ondrej Mosnacek 2018-08-24 12:00 ` [PATCH ghak10 v5 1/2] audit: Add functions to log time adjustments Ondrej Mosnacek 2018-08-24 18:33 ` John Stultz 2018-08-27 8:28 ` Ondrej Mosnacek 2018-09-13 15:54 ` Richard Guy Briggs 2018-09-17 12:33 ` Ondrej Mosnacek 2018-08-27 7:50 ` Miroslav Lichvar 2018-08-27 9:13 ` Ondrej Mosnacek 2018-08-27 16:38 ` Steve Grubb [this message] 2018-08-27 16:38 ` Steve Grubb 2018-09-13 13:59 ` Ondrej Mosnacek 2018-09-13 15:14 ` Richard Guy Briggs 2018-09-17 12:32 ` Ondrej Mosnacek 2018-09-14 3:09 ` Paul Moore 2018-09-17 12:33 ` Ondrej Mosnacek 2018-09-14 3:18 ` Paul Moore 2018-09-14 15:16 ` Richard Guy Briggs 2018-09-14 15:34 ` Steve Grubb 2018-09-14 16:24 ` Richard Guy Briggs 2018-09-17 14:36 ` Paul Moore 2018-09-17 12:38 ` Ondrej Mosnacek 2018-09-17 14:20 ` Richard Guy Briggs 2018-09-17 14:50 ` Paul Moore 2018-09-21 11:21 ` Ondrej Mosnacek 2018-09-22 20:42 ` Paul Moore 2018-09-22 20:42 ` Paul Moore 2018-08-24 12:00 ` [PATCH ghak10 v5 2/2] timekeeping/ntp: Audit clock/NTP params adjustments Ondrej Mosnacek 2018-08-24 19:47 ` Richard Guy Briggs 2018-08-24 20:20 ` John Stultz 2018-08-24 20:20 ` John Stultz 2018-08-27 11:35 ` Ondrej Mosnacek 2018-08-27 11:45 ` Miroslav Lichvar 2018-08-27 12:02 ` Ondrej Mosnacek 2018-08-27 21:42 ` Thomas Gleixner 2018-09-13 15:35 ` Richard Guy Briggs
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4819575.TSNxuEWROA@x2 \ --to=sgrubb@redhat.com \ --cc=john.stultz@linaro.org \ --cc=linux-audit@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mlichvar@redhat.com \ --cc=omosnace@redhat.com \ --cc=paul@paul-moore.com \ --cc=rgb@redhat.com \ --cc=sboyd@kernel.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.