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

[Steve Grubb]

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.

-Steve