public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>,
	Linux-Audit Mailing List <linux-audit@redhat.com>
Subject: Re: [RFC PATCH ghak10 2/3] audit: Add the audit_adjtime() function
Date: Tue, 19 Jun 2018 16:52:06 -0400	[thread overview]
Message-ID: <1707958.iSX8Mzt5vJ@x2> (raw)
In-Reply-To: <CAFqZXNvsvOCvPHU7rarpz3hqjtn=Znet8kV9L2E+4M6h491OZw@mail.gmail.com>

On Tuesday, June 19, 2018 4:57:37 AM EDT Ondrej Mosnacek wrote:
> 2018-06-18 20:39 GMT+02:00 Steve Grubb <sgrubb@redhat.com>:
> > On Friday, June 15, 2018 8:45:22 AM EDT Ondrej Mosnacek wrote:
> >> This patch adds a new function that shall be used to log any
> >> modification of the system's clock (via the adjtimex() syscall).
> >> 
> >> The function logs an audit record of type AUDIT_TIME_ADJUSTED with the
> >> following fields:
> >> * txmodes  (the 'modes' field of struct timex)
> >> * txoffset (the 'offset' field of struct timex)
> >> * txfreq   (the 'freq' field of struct timex)
> >> * txmaxerr (the 'maxerror' field of struct timex)
> >> * txesterr (the 'esterror' field of struct timex)
> >> * txstatus (the 'status' field of struct timex)
> >> * txconst  (the 'constant' field of struct timex)
> >> * txsec, txusec (the 'tv_sec' and 'tv_usec' fields of the 'time' field
> >> of struct timex (respectively))
> >> * txtick   (the 'tick' field of struct timex)
> > 
> > Are all of these fields security relevant? Primarily what we need to know
> > is if time is being adjusted. This is relevant because a bad guy may
> > adjust system time to make something appear to happen earlier or later
> > than it really did which make correlation hard or impossible.
> 
> This is still an open question for me... On the one hand, we might
> want to know exactly what the bad guy was trying to do ("He changed
> the offset to 500 ms." vs. just "He adjusted the clock."), on the
> other hand, we may not really care and consider it yet another junk
> data in the logs... A possible compromise could be to log only
> relevant fields (see 'Possible improvements' in the commit message).
> Assuming ntpd or other authorized applications would only modify
> one/few variables at a time, this would add only a few fields to the
> record each time.

I think we want the modes field so that we know what was changed. But do we 
really need to know maxerror or status? I think we should limit this to the 
modes and any value of a time adjustment. 

> Note that this new auxiliary record gets only logged on *modifying*
> operations, which should not be that frequent, and thus it shouldn't
> be a problem to output a bit of potentially useful information.

We're after just security information.

> That said, I don't mind logging just an empty record if that is
> preferred.

An empty buffer doesn't tell us what was adjusted.

Thanks,
-Steve

  reply	other threads:[~2018-06-19 20:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 12:45 [RFC PATCH ghak10 1/3] audit: Add AUDIT_TIME_ADJUSTED record type Ondrej Mosnacek
2018-06-15 12:45 ` [RFC PATCH ghak10 2/3] audit: Add the audit_adjtime() function Ondrej Mosnacek
2018-06-18 18:39   ` Steve Grubb
2018-06-19  8:57     ` Ondrej Mosnacek
2018-06-19 20:52       ` Steve Grubb [this message]
2018-06-19 21:08         ` Lenny Bruzenak
2018-06-21 11:28         ` Ondrej Mosnacek
2018-06-15 12:45 ` [RFC PATCH ghak10 3/3] ntp: Audit valid attempts to adjust the clock Ondrej Mosnacek
2018-06-16 16:44   ` Richard Guy Briggs
2018-06-18  7:35     ` Ondrej Mosnacek
2018-06-18 15:14       ` Richard Guy Briggs
2018-06-19  8:30         ` Ondrej Mosnacek
2018-06-19 16:22           ` 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=1707958.iSX8Mzt5vJ@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=omosnace@redhat.com \
    --cc=rgb@redhat.com \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox