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

[Paul Moore]

On Wed, Jul 18, 2018 at 6:34 PM Steve Grubb <sgrubb at redhat.com> wrote:
> On Wednesday, July 18, 2018 3:59:24 PM EDT Paul Moore 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?
>
> Well, I think that we need to make it obvious that a time setting has changed
> as in a y/n answer. Doing a comparison of the time to get a y/n answer is
> less obvious if you are doing a grep.

Presumably we would only be emitting this new record when the system
time changes as the result of a time setting change so the simple
presence of this record should be sufficient to indicate a time
change.

> Also, what time will the event have? I
> presume that the event will have the new time since we are on the exit
> filter. So, do we really need to collect that?

The audit event timestamp is not guaranteed to be the same as the user
supplied value so we should explicitly log the old/new system time.

-- 
paul moore
www.paul-moore.com