Re: [RFC PATCH ghak10 v3 0/3] audit: Log modifying adjtimex(2) calls
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