[RFC PATCH ghak10 v3 0/3] audit: Log modifying adjtimex(2) calls

Paul Moore paul at paul-moore.com
Thu Jul 19 23:01:50 UTC 2018


On Thu, Jul 19, 2018 at 3:36 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> On Wed, Jul 18, 2018 at 9:59 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Wed, Jul 18, 2018 at 3:36 PM Steve Grubb <sgrubb at redhat.com> wrote:
> > > On Wednesday, July 18, 2018 2:36:11 PM EDT Paul Moore wrote:
> > > > > Changes in v2:
> > > > > - The audit_adjtime() function has been modified to only log those
> > > > > fields that contain values that are actually used, resulting in more
> > > > > compact records.
> > > > > - The audit_adjtime() call has been moved to do_adjtimex() in
> > > > > timekeeping.c
> > > > > - Added an additional patch (for review) that simplifies the detection
> > > > > if the syscall is read-only.
> > > >
> > > > Looking at these new records, and trying to guess a bit at the
> > > > original intent of the feature request, I think we may be going a bit
> > > > overboard with the information we are logging.  I'm thinking all we
> > > > really need to capture in the audit log is the system time both before
> > > > and after the change (for the sake of simplicity I suggest using a
> > > > data format similar to the audit record timestamp).
> > > >
> > > > While I created the GH issue for this, I believe the original request
> > > > came from a Red Hat BZ that Steve created; Steve, what sort of
> > > > certification requirements (if any?) are there for logging system time
> > > > changes?
> > >
> > > That we record any attempts to change the system time. The problem is that
> > > adjtimex passes a data structure that is opaque to user space. So, we can't
> > > tell if someone is setting time, adjusting a tolerance, or simply retrieving
> > > status.
> > >
> > > With stime, we can clearly see the time that was sent into the kernel and it
> > > unconditionally sets time. With settimeofday, it uses a data structure that
> > > we cannot see, but whatever the contents are we are definitely setting time.
> > > Same goes for clock_settime. Only in 1 case do we actually see what the time
> > > is. So, that is not really needed. So, I think what we need to know is did
> > > the syscall do anything that adjusted the system's notion of time? And that's
> > > all.
> >
> > So presumably my above suggestion of simply recording the system time
> > both before and after the change would be sufficient, yes?
>
> I wouldn't say this is the right approach here, for two reasons that
> I'll try to explain below.
>
> adjtimex(2) can be basically used for two major types of adjustment:
> 1. for (immediately) injecting offset into system time,
> 2. for changing NTP status variables.
>
> (1.) is the more obvious and simple adjustment, which *directly*
> alters the system time. For this adjustment the current proposed
> solution simply logs the delta, by which the time is adjusted (it can
> be retrieved easily from the supplied timex struct). In my opinion,
> logging of this delta is more explicit than logging the timestamps
> (which might not give the precise offset anyway, since time might flow
> between the two timestamps) and is also more easily grepped in the
> logs, as Steve pointed out in his reply. For example, you can quickly
> filter out adjustments of less than +/-1 second by simply comparing
> the offset in the records.

I remain unconvinced for this case, I would argue that the fact that
the new system time is more useful than the delta, but it might not
matter considering the second case below.

> (2.) is a lot more tricky... These adjustments modify the variables of
> the NTP algorithm, which is quite complex and it is not obvious how it
> influences the system time. From my understanding, the algorithm is
> used for adjustments that require smooth transition over time - such
> as (or maybe this is the only use case) inserting a leap second. Note
> that in this case, just logging timestamp before and after the syscall
> is not sufficient, since the change doesn't happen immediately, but in
> small increments that are gradually added *after* the syscall already
> finished. I don't know if (or which of) these adjustments can be used
> for a real attack, but at least the leap second insertion sounds like
> something that could be used to shift the time without being easily
> detected. This is why I am wary of throwing things out from the
> logging until we understand what is truly important and what is not.

Okay, it sounds like we need to log some of these variables, but which
ones are relevant is still unknown (all?).  I would suggest a bit more
research on this so that we can say with some certainty which fields
are important, please include this information in the commit
descriptions so we have it in the git log for future use.

-- 
paul moore
www.paul-moore.com




More information about the Linux-audit mailing list