Date: Tue, 24 Aug 1999 23:59:08 +0200 From: "H. Eckert" <ripley@nostromo.in-berlin.de> To: freebsd-security@FreeBSD.ORG Subject: Re: Securelevel 3 and setting time Message-ID: <19990824235908.B70739@server.nostromo.in-berlin.de> In-Reply-To: <19990822194140.623D211@woodstock.monkey.net>; from Jon Hamilton on Sun, Aug 22, 1999 at 02:41:40PM -0500 References: <19990822112923.6666.qmail@alice.gba.oz.au> <19990822194140.623D211@woodstock.monkey.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Jon Hamilton (hamilton@pobox.com): > - some people don't care about "the" correct time, as long as their > machines all agree about what they _think_ the time is (e.g. to keep > NFS happy on an internal network) Additionally it depends quite a lot on how correct you want to be. For most home users (that is, those people who are not permanently connected to the net) it is absolutely sufficient to have one local time master that all other machines sync themselves to (hey, a lot of people even may have only one machine at all ;-) and that syncs to the correct time once in a while when it's connected to the net. This is what I do (my server's running xntpd in behalf of the other machines and updates its clock during the daily poll for mail) and it's what the fellow does who started this whole thread in the first place. The only problem being he put his server into an elevated secure level and synchronized the clock rarely enough to drift too far away to be corrected at that secure level in one step. Now, anybody who's got a real reason to keep their time more accurate than that should be obliged to invest into that accuracy. Either by providing a different source for "the" time or by configuring the machine to take care of it by synching itself more often. Radio synched clocks to be connected to a serial port aren't expensive. Activating the network connection once or twice an hour instead of once a day isn't that expensive either. You get what you pay for and YMMV. The main question we haven't come to a conclusion so far is what action should(n't) be taken as a possible solution for the "rarely synched clock in an elevated secure level" scenario. - Loosen security and allow for bigger time jumps ? - Forcing the admin to sync the clock more often ? - Enabling ntpdate to distribute the time adjustments into several smaller jumps instead of a big leap ? Greetings, Ripley To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990824235908.B70739>