Date: Fri, 19 Jan 2018 00:33:20 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-bugs@freebsd.org Subject: Re: [Bug 225265] Lack of monotonic clock prolongs the default sudo 5 minutes password caching as long as suspend lasts Message-ID: <20180118232840.C1938@besplex.bde.org> In-Reply-To: <bug-225265-8@https.bugs.freebsd.org/bugzilla/> References: <bug-225265-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Jan 2018 a bug that doesn't want replies@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180118232840.C1938>