[Bug 225265] Lack of monotonic clock prolongs the default sudo 5 minutes password caching as long as suspend lasts

[Bruce Evans]

On Wed, 17 Jan 2018 a bug that doesn't want replies at freebsd.org wrote:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225265
>
>            Bug ID: 225265
>           Summary: Lack of monotonic clock prolongs the default sudo 5
>                    minutes password caching as long as suspend lasts
>
> The five minute caching period of the password in sudo is prolonged when the
> laptop is suspended. For example: In the terminal I issue a command with sudo,
> I enter my password, one minute later I suspend the laptop, after one hour I
> resume and still can issue sudo cammands without being asked for my password
> for the rest of the five minutes that remained from before suspending.
> ...
> Originally I have reported a bug directly to the sudo bugzilla:
> https://bugzilla.sudo.ws/show_bug.cgi?id=779
>
> But as can be seen in the comments Todd C. Miller answered:
>
> "FreeBSD doesn't appear to have a monotonic clock that runs while the machine
> is suspended.  The choice is between using a clock that can run backward,
> potentially defeating the point of the timestamp file, or one that cannot run
> backward but that is not incremented while suspended.
>
> Currently, sudo uses the second option.  On most other systems, the monotonic
> clock either runs while suspended or an alternate clock is available which
> does.  I consider this a FreeBSD failing, rather than a sudo one."

It is well known that the monotonic clock is broken (or just low quality)
across suspend.  It is interesting that this gives security holes.  Perhaps
security-related software shouldn't trust it.

POSIX specifies that "If the Monotonic Clock option is supported, ...
the value returned by clock_gettime() represents the amount of time (in
seconds and nanoseconds) since an unspecified point in the past (for
example, system start-up time, or the Epoch).  This point does not change
after system start-up time."

Note that this doesn't specify what time is or require any particular
accuracy.  Only quality of implementation requires the time to resemble
physical time or do this accurately.  The mononotic time should be as
close as possible to a physical time difference, subject to the requirement
that its derivatives also be as close as possible to physical derivatives.
In practice, this means that it should be the real time less leap seconds
adjustments, less a fixed offset (Epoch minus unspecified point in the past),
with complications for derivative(s).

In FreeBSD under normal operation, there are no complications for
derivatives.  When ntpd adjusts the rate, the same adjustment is applied
to the realtime clock and the monotonic clock, so that they both advance
at approximately the physical rate (first derivative of clock relative
to physical == 1).  Problems occur if the real time is stepped.  If
the step is backwards, then of course the monotonic clock must not be
stepped backwards, and if the step is forwards then the monotonic clock
should not be stepped forwards.  In both cases, the monotonic clock
should usually be skewed instead of stepped.  However, after suspension,
it is better to do a large step forwards on resume.  Nothing except
pending timeouts should notice the large step (and it is correct for
them to notice) because nothing should be running until the resume completes,
while skewing later gives a non-physical derivative for a very long time.

The bug can easily be seen using uptime(1) and "sysctl kern.boottime".  Uptime
only shows the non-suspended uptime (with other errors from never stepping
or skewing the monotonic clock).  kern.boottime should be the "unchangeable
point in the past", but it changes for suspension and other missing steps/
skews of the monotonic clock.

The bug at least used to be easy to see using "sleep 60 & zzz" with suspension
for about 30 seconds.  The sleep then takes 60 + 30 seconds instead of the
requested 60 seconds.  Most timeouts are broken similarly, since most are
relative to the monotonic clock.  Absolute timeouts make no sense relative
to clocks that sometimes stop.  Timeouts relative to the real time clock
have a chance of working, but they still won't if they are implemented using
timeouts on the monotonic clock.

On resume, most timeouts should expire and there is a problem handling
them in the right order and not too fast.  The never-working
APM_FIXUP_CALLTODO non-option attempted to fix this 20 years ago.

Bruce