Date: Tue, 15 Jan 2002 13:33:39 -0800 From: "Crist J . Clark" <cristjc@earthlink.net> To: FreeBSD@jovi.net Cc: freebsd-gnats-submit@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: kern/33904: secure mode bug Message-ID: <20020115133339.A31328@blossom.cjclark.org> In-Reply-To: <200201151526.g0FFQFX02180@grant.org>; from FreeBSD@jovi.net on Tue, Jan 15, 2002 at 10:26:15AM -0500 References: <200201142344.g0ENimK91227@freefall.freebsd.org> <20020115011230.D28767@blossom.cjclark.org> <200201151526.g0FFQFX02180@grant.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 15, 2002 at 10:26:15AM -0500, FreeBSD@jovi.net wrote:
> Thanks for your reply.
> I suggest escalating the trouble.
> Correct time is mission-critical on many systems
> and this is an issue of unreliable service under FreeBSD.
>
> A settimeofday other than that programmed is worse than doing nothing.
> Three orders of magnitude is a complete failure by every reasonable standard.
> Breaking date, ntpdate, ntpd, ... is a reliable indication of severe failure.
The behavior is specifically designed not to break something like
ntpd(8) which only makes tiny changes to the system time.
> These programs now need rewriting to operate reliably.
At securelevel(8) >= 2, the ability to change the clock by more than
+/-1 s is removed for security reasons. Things like date(1) and
ntpdate(8) _will_ be broken. The only question is, how to best handle
the breakage? There are basically two approaches,
1) Have system calls that request an illegal time change completely
fail.
2) Have system calls that request an illegal time change have the
time changed as much as allowed and not return failure.
When calls to change system time fail in option (1), we may see
programs bailing out or reporting strange failures (failure to set the
time is not usually expected). When option (2) is being used, programs
will not be bailing out because things failed, but we might get odd
behavior... and I think we are more likely to have some confused users
in case (2).
Finally, nothing about this prevents accurate timekeeping. First, if
this is a really big problem for you, don't run at securelevel(8) >= 2.
By design, securelevel(8) breaks stuff. If it breaks things you want
or need, don't use it. If you do want accurate timekeeping and
securelevel(8), do something like run ntpdate(8) during system startup
before securelevel(8) is raised and run ntpd(8). Generally, ntpd(8)'s
time adjustments will not be hampered by securelevel(8) settings.
> Date: Tue, 15 Jan 2002 01:12:30 -0800
> From: "Crist J . Clark" <cjc@FreeBSD.ORG>
> Cc: freebsd-gnats-submit@FreeBSD.ORG
>
> On Mon, Jan 14, 2002 at 03:44:48PM -0800, D. McCullough wrote:
> [snip]
>
> > >Description:
> > settimeofday silently fails in secure mode.
> >
> > I wasted a lot of time baffled --
> > this makes all the various date
> > apps and clients silently fail.
>
> The problem is that it doesn't _completely_ fail.
>
> > >Fix:
> > When an operation prohibited by secure mode fails,
> > this failure must be accurately reported by the API.
>
> If you run your test program,
>
> # ./testtime
> gettimeofday = 0; t = 1011071149.590024
> settimeofday = 0; t = 1011067549.590024
> gettimeofday = 0; t = 1011071148.591402
>
> At securelevel == 2, we see that the time _has_ been changed by the
> call, but like the log message says,
>
> Jan 14 21:05:44 <kern.crit> bubbles kernel: Time adjustment clamped to -1 second
>
> So the call of settimeofday(2) didn't actually fail due to "permission
> denied," but the result is not exactly what the caller expected either.
>
> Now, whether this whole approach is wrong is more of a discussion for
> freebsd-arch@freebsd.org.
--
"It's always funny until someone gets hurt. Then it's hilarious."
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020115133339.A31328>