From nobody@FreeBSD.org  Mon Jan 14 15:44:49 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 8D3EB37B41E
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 14 Jan 2002 15:44:48 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g0ENimK91227;
	Mon, 14 Jan 2002 15:44:48 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200201142344.g0ENimK91227@freefall.freebsd.org>
Date: Mon, 14 Jan 2002 15:44:48 -0800 (PST)
From: "D. McCullough" <freebsd@jovi.net>
To: freebsd-gnats-submit@FreeBSD.org
Subject: secure mode bug
X-Send-Pr-Version: www-1.0
X-GNATS-Notify: ru

>Number:         33904
>Category:       kern
>Synopsis:       secure mode bug
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    nsayer
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 14 15:50:01 PST 2002
>Closed-Date:    Mon Feb 10 22:05:32 PST 2003
>Last-Modified:  Mon Feb 10 22:05:32 PST 2003
>Originator:     D. McCullough
>Release:        FreeBSD 4.4-RELEASE
>Organization:
Jovi.Net, Inc.
>Environment:
FreeBSD diazepam.ai.mit.edu 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Tue Sep 18 11:57:08 PDT 20\
01     murray@builder.FreeBSD.org:/usr/src/sys/compile/GENERIC  i386

>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.


>How-To-Repeat:
/* Here's C code to demo the bug,
settimeofday will report success
yet the time remains unchanged.*/

#include <stdio.h>
#include <sys/time.h>

static struct timeval t;
static struct timezone tz;

main ()
{
  int r = gettimeofday(&t, &tz);

  printf ("gettimeofday = %d; t = %ld.%06ld\n",
          r, t.tv_sec, t.tv_usec);
  r && exit (r);

  t.tv_sec -= 3600;
  r = settimeofday(&t, &tz);
  printf ("settimeofday = %d; t = %ld.%06ld\n",
          r, t.tv_sec, t.tv_usec);
  r && exit (r);

  r = gettimeofday(&t, &tz);
  printf ("gettimeofday = %d; t = %ld.%06ld\n",
          r, t.tv_sec, t.tv_usec);
  return r;
}

>Fix:
When an operation prohibited by secure mode fails,
this failure must be accurately reported by the API.
>Release-Note:
>Audit-Trail:

From: "Crist J . Clark" <cjc@FreeBSD.ORG>
To: "D. McCullough" <freebsd@jovi.net>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Tue, 15 Jan 2002 01:12:30 -0800

 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
Responsible-Changed-From-To: freebsd-bugs->nsayer 
Responsible-Changed-By: ru 
Responsible-Changed-When: Tue Jan 15 02:21:36 PST 2002 
Responsible-Changed-Why:  
Nick, could you please document the actual behavior of settimeofday() 
syscall in lib/libc/sys/gettimeofday.2 after your changes to 
kern_time.c in revisions 1.62 and 1.64? 

Thanks. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33904 
State-Changed-From-To: open->analyzed 
State-Changed-By: ru 
State-Changed-When: Tue Jan 15 02:23:29 PST 2002 
State-Changed-Why:  
Some modifications are needed to the settimeofday(2) manpage 
to document the actual behavior of this syscall after the 
changes in kern_time.c,v 1.62 and 1.64. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33904 

From: FreeBSD@jovi.net
To: cjc@FreeBSD.ORG
Cc: freebsd@jovi.net, freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Tue, 15 Jan 2002 10:26:15 -0500 (EST)

 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.
 These programs now need rewriting to operate reliably.
 
 		Cheers
 			--Devon
 	 /"\
 	 \ /	 ASCII Ribbon Campaign
 	  X	  Help Cure HTML Mail
 	 / \
 
 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

From: Bruce Evans <bde@zeta.org.au>
To: <ru@FreeBSD.ORG>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>, <nsayer@FreeBSD.ORG>
Subject: Re: kern/33904: secure mode bug
Date: Wed, 16 Jan 2002 03:46:31 +1100 (EST)

 On Tue, 15 Jan 2002 ru@FreeBSD.ORG wrote:
 
 > Nick, could you please document the actual behavior of settimeofday()
 > syscall in lib/libc/sys/gettimeofday.2 after your changes to
 > kern_time.c in revisions 1.62 and 1.64?
 
 This belongs in the BUGS section if anywhere.
 
 The changes also affect clock_settime(2).
 
 Bruce
 

From: Terry Lambert <tlambert2@mindspring.com>
To: FreeBSD@jovi.net
Cc: cjc@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG,
	freebsd-arch@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Tue, 15 Jan 2002 12:56:58 -0800

 FreeBSD@jovi.net wrote:
 > Thanks for your reply.
 > I suggest escalating the trouble.
 > Correct time is mission-critical on many systems
 
 Agreed.
 
 > and this is an issue of unreliable service under FreeBSD.
 
 Disagree: FreeBSD is ensuring the correctness of the time by
 disallowing a delta which is so large as to be useful to
 someone attempting to hack date stamps on files.
 
 If you want to "reliably" change the time by a large delta,
 then there are only three valid circumstances in which this
 should be done:
 
 1)	Initial installation of a system (in which case you
 	have control over it to the level of being able to
 	not set the secure mode up before you have made the
 	adjustment).
 
 2)	You are the Pope, and you are changing the calendar
 	again (I'd be happy to fix it for you, your eminence,
 	particularly if I can let it be known you use FreeBSD).
 
 3)	You just got back from a relatavistic flight that
 	resulted in the on board computer in your space
 	ship (I will fix it for free for you, if I am
 	allowed to do it on site, and take the vehicle out
 	for a spin afterwards, to verify that the large
 	delats are now allowed, when necessary).
 
 > A settimeofday other than that programmed is worse than doing nothing.
 
 Particularly if you are trying to hack someone...
 
 > Three orders of magnitude is a complete failure by every reasonable
 > standard.  Breaking date, ntpdate, ntpd, ... is a reliable indication
 > of severe failure. These programs now need rewriting to operate reliably.
 
 I guess you've never used NTP when the drift exceeds an hour
 or so, without having intentially set your security mode to
 disable changes over one second?
 
 The change is refused if the delta exceeds a maximum delta
 time, as being "unreasonable" by the NTP code itself, and
 you have to manually synchronize the clock to get it "in
 the neighborhood" in the first place before it will start
 working again.
 
 -- Terry

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
Date: Tue, 15 Jan 2002 13:33:39 -0800

 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

From: Devon@jovi.net
To: cjclark@alum.mit.edu
Cc: FreeBSD@jovi.net, freebsd-gnats-submit@FreeBSD.ORG,
	freebsd-arch@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Tue, 15 Jan 2002 17:02:47 -0500 (EST)

    (failure to set the time is not usually expected)
 
 Programs seem to handle it ok when user is not root.

From: "Crist J . Clark" <cjc@FreeBSD.ORG>
To: FreeBSD@jovi.net
Cc: freebsd-questions@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG,
	bug-followup@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Tue, 15 Jan 2002 21:03:03 -0800

 On Tue, Jan 15, 2002 at 03:03:42PM -0500, FreeBSD@jovi.net wrote:
 > It would help to document or fix date/ntpdate/ntpd/...
 
 ntpdate(8) and ntpd(8) are contributed software. As far as I can tell,
 FreeBSD uses "virgin" imports. There is no local customization of the
 code. Maintaining local modifications to code maintained by outside
 vendors is expensive and therefore needs a lot of justification.
 
 > to warn of this "clock clamp" trouble
 
 You do get a log message generated at <kern.crit>. That tends to be
 something people notice.
 
 > or better yet
 > fix settimeofday to return EPERM instead of trying
 > to second-guess the intent of the programmer.
 
 That might be a valid option. Would you be willing to patch settime()
 (in sys/kern/kern_time.c)? Would you be willing to test patches to see
 if they don't break things even worse?
 
 > If not, settimeofday documentation must clarify this silent lossage
 > of setting a time other than what the calling program specified.
 
 This is true. The statements in settimeofday(2) about "secure mode"
 are actually incorrect. I'll commit a fix shortly.
 -- 
 "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

From: Sheldon Hearn <sheldonh@starjuice.net>
To: "Crist J . Clark" <cjc@FreeBSD.ORG>
Cc: FreeBSD@jovi.net, freebsd-questions@FreeBSD.ORG,
	freebsd-arch@FreeBSD.ORG, bug-followup@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug 
Date: Wed, 16 Jan 2002 10:56:28 +0200

 On Tue, 15 Jan 2002 21:03:03 PST, "Crist J . Clark" wrote:
 
 > On Tue, Jan 15, 2002 at 03:03:42PM -0500, FreeBSD@jovi.net wrote:
 > > It would help to document or fix date/ntpdate/ntpd/...
 > 
 > ntpdate(8) and ntpd(8) are contributed software. As far as I can tell,
 > FreeBSD uses "virgin" imports. There is no local customization of the
 > code. Maintaining local modifications to code maintained by outside
 > vendors is expensive and therefore needs a lot of justification.
 
 And that's not the point. :-)
 
 Basically, we're being asked to compensate for poor conduct on the
 part of an administrator who changed the securelevel without knowing
 what he was doing.  We can't compensate for poor change control in our
 documentation.
 
 This is akin to documenting in the manual pages of _every_ utility that
 writes to some file in the /var hierarchy, that the /var filesystem must
 not be mounted read-only.
 
 Let's just close the PR already.
 
 Ciao,
 Sheldon.

From: Sheldon Hearn <sheldonh@starjuice.net>
To: "Crist J . Clark" <cjc@FreeBSD.ORG>
Cc: FreeBSD@jovi.net, freebsd-questions@FreeBSD.ORG,
	freebsd-arch@FreeBSD.ORG, bug-followup@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug 
Date: Wed, 16 Jan 2002 10:58:43 +0200

 On Wed, 16 Jan 2002 10:56:28 +0200, Sheldon Hearn wrote:
 
 > Let's just close the PR already.
 
 And before anyone gets hysterical, I meant close it as per ru's request
 to nsayer, not just summarily close it without _any_ action. :-)
 
 Ciao,
 Sheldon.

From: "Crist J . Clark" <cristjc@earthlink.net>
To: Sheldon Hearn <sheldonh@starjuice.net>
Cc: FreeBSD@jovi.net, freebsd-questions@FreeBSD.ORG,
	freebsd-arch@FreeBSD.ORG, bug-followup@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Wed, 16 Jan 2002 01:09:37 -0800

 On Wed, Jan 16, 2002 at 10:56:28AM +0200, Sheldon Hearn wrote:
 > 
 > 
 > On Tue, 15 Jan 2002 21:03:03 PST, "Crist J . Clark" wrote:
 > 
 > > On Tue, Jan 15, 2002 at 03:03:42PM -0500, FreeBSD@jovi.net wrote:
 > > > It would help to document or fix date/ntpdate/ntpd/...
 > > 
 > > ntpdate(8) and ntpd(8) are contributed software. As far as I can tell,
 > > FreeBSD uses "virgin" imports. There is no local customization of the
 > > code. Maintaining local modifications to code maintained by outside
 > > vendors is expensive and therefore needs a lot of justification.
 > 
 > And that's not the point. :-)
 > 
 > Basically, we're being asked to compensate for poor conduct on the
 > part of an administrator who changed the securelevel without knowing
 > what he was doing.  We can't compensate for poor change control in our
 > documentation.
 
 I think there is a valid point. The settimeofday(2) call returns
 success even though the change requested by the call is not really
 done. This is somewhat questionable behavior. The documentation for
 settimeofday(2) was not clear about how this works under elevated
 securelevel(8), and in fact, the documentation is actually wrong
 (which I will fix shortly).
 -- 
 "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

From: Sheldon Hearn <sheldonh@starjuice.net>
To: cjclark@alum.mit.edu
Cc: FreeBSD@jovi.net, freebsd-questions@FreeBSD.ORG,
	freebsd-arch@FreeBSD.ORG, bug-followup@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug 
Date: Wed, 16 Jan 2002 11:18:39 +0200

 On Wed, 16 Jan 2002 01:09:37 PST, "Crist J . Clark" wrote:
 
 > I think there is a valid point. The settimeofday(2) call returns
 > success even though the change requested by the call is not really
 > done. This is somewhat questionable behavior. The documentation for
 > settimeofday(2) was not clear about how this works under elevated
 > securelevel(8), and in fact, the documentation is actually wrong
 > (which I will fix shortly).
 
 I'm not disputing the need to correct settimeofday(2).  The PR is
 already assigned to nsayer with a request to do this.
 
 But that's it.  The notion of changing the documentation of all userland
 consumers is what I'm challenging.
 
 Ciao,
 Sheldon.

From: Bruce Evans <bde@zeta.org.au>
To: <cjclark@alum.mit.edu>
Cc: Sheldon Hearn <sheldonh@starjuice.net>, <FreeBSD@jovi.net>,
	<freebsd-questions@FreeBSD.ORG>, <freebsd-arch@FreeBSD.ORG>,
	<bug-followup@FreeBSD.ORG>
Subject: Re: kern/33904: secure mode bug
Date: Thu, 17 Jan 2002 00:32:23 +1100 (EST)

 On Wed, 16 Jan 2002, Crist J . Clark wrote:
 
 > On Wed, Jan 16, 2002 at 10:56:28AM +0200, Sheldon Hearn wrote:
 > > Basically, we're being asked to compensate for poor conduct on the
 > > part of an administrator who changed the securelevel without knowing
 > > what he was doing.  We can't compensate for poor change control in our
 > > documentation.
 >
 > I think there is a valid point. The settimeofday(2) call returns
 > success even though the change requested by the call is not really
 > done. This is somewhat questionable behavior. The documentation for
 > settimeofday(2) was not clear about how this works under elevated
 > securelevel(8), and in fact, the documentation is actually wrong
 > (which I will fix shortly).
 
 Don't forget to "fix" the Standard way to set times (clock_settime(2))
 and the standard that says that clock_settime() shall set the time or
 fail (POSIX).
 
 The man pages are also misleading at best about adjtime(2) setting the
 time backwards.  adjtime(2) can't go backwards fast enough to do more
 than retard the advance of the time, except possibly for bugs.
 
 The original "fix" may be moot because ntpd now uses the kernel pll
 automagically by default.  Large steps by ntpdate and ntpd can't be
 replaced by the kernel pll, but the don't work anyway when securelevel
 > 1.
 
 Bruce
 

From: Terry Lambert <tlambert2@mindspring.com>
To: "Crist J . Clark" <cjc@FreeBSD.ORG>
Cc: FreeBSD@jovi.net, freebsd-questions@FreeBSD.ORG,
	freebsd-arch@FreeBSD.ORG, bug-followup@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Wed, 16 Jan 2002 12:02:47 -0800

 "Crist J . Clark" wrote:
 > On Tue, Jan 15, 2002 at 03:03:42PM -0500, FreeBSD@jovi.net wrote:
 > > or better yet
 > > fix settimeofday to return EPERM instead of trying
 > > to second-guess the intent of the programmer.
 > 
 > That might be a valid option. Would you be willing to patch settime()
 > (in sys/kern/kern_time.c)? Would you be willing to test patches to see
 > if they don't break things even worse?
 
 Bad idea.
 
 Specifically, the clamping doesn't prevent small deltas from
 being applied, and it does not prevent larger deltas from
 being applied iteratively in order to actually get a larger
 delta.
 
 This means that a delta of several minutes *will* eventually
 cause the clock to slowly approach the correct value, until
 it is eventually correct.
 
 Returning an error all the time wouldn't let this happen,
 since you would prevent, not clam, the adjustment.
 
 -- Terry

From: Terry Lambert <tlambert2@mindspring.com>
To: cjclark@alum.mit.edu
Cc: Sheldon Hearn <sheldonh@starjuice.net>, FreeBSD@jovi.net,
	freebsd-questions@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG,
	bug-followup@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Wed, 16 Jan 2002 12:21:06 -0800

 "Crist J . Clark" wrote:
 > The settimeofday(2) call returns
 > success even though the change requested by the call is not really
 > done. This is somewhat questionable behavior. The documentation for
 > settimeofday(2) was not clear about how this works under elevated
 > securelevel(8), and in fact, the documentation is actually wrong
 > (which I will fix shortly).
 
 This is BS.  It's not documented how it works in jails, either,
 or under vmware.
 
 THe call is done, it's just that the caller was, in context,
 requesting something other than what they thought they were
 requesting.
 
 In fact, any delta in excess of 1 is a request for 1, at that
 secure level.  The call is doing *exactly* what it is supposed
 to do.
 
 -- Terry

From: "Crist J . Clark" <cjc@FreeBSD.ORG>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Sheldon Hearn <sheldonh@starjuice.net>, FreeBSD@jovi.net,
	freebsd-questions@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG,
	bug-followup@FreeBSD.ORG
Subject: Re: kern/33904: secure mode bug
Date: Wed, 16 Jan 2002 18:02:40 -0800

 On Wed, Jan 16, 2002 at 12:21:06PM -0800, Terry Lambert wrote:
 > "Crist J . Clark" wrote:
 > > The settimeofday(2) call returns
 > > success even though the change requested by the call is not really
 > > done. This is somewhat questionable behavior. The documentation for
 > > settimeofday(2) was not clear about how this works under elevated
 > > securelevel(8), and in fact, the documentation is actually wrong
 > > (which I will fix shortly).
 > 
 > This is BS.
 
 I don't think so.
 
 > It's not documented how it works in jails, either,
 > or under vmware.
 
 But settimeofday(2) _does_ claim to document what happens, but it is
 flat out wrong (out of date),
 
      Only the super-user may set the time of day or time zone.  If the system
      is running in secure mode (see init(8)), the time may only be advanced.
      This limitation is imposed to prevent a malicious super-user from setting
      arbitrary time stamps on files.  The system time can still be adjusted
      backwards using the adjtime(2) system call even when the system is
      secure.
 
 Read the comments for settime() and the rest of the code in
 kern_time.c, and test it. This is clearly not how things really work.
 -- 
 Crist J. Clark                     |     cjclark@alum.mit.edu
                                    |     cjclark@jhu.edu
 http://people.freebsd.org/~cjc/    |     cjc@freebsd.org
State-Changed-From-To: analyzed->feedback 
State-Changed-By: nsayer 
State-Changed-When: Tue Apr 9 11:01:58 PDT 2002 
State-Changed-Why:  
This is not a problem with the code, but rather the documentation. 
I've asked for help in getting the man page fixed, but not heard 
anything back. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=33904 

From: FreeBSD@Jovi.Net
To: nsayer@FreeBSD.org
Cc: ru@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/33904: secure mode bug
Date: Tue, 9 Apr 2002 14:44:25 -0400 (EDT)

 Bug is in the code.
 Perpetuated by policy error.
 Silent DWIM/failure is never acceptable policy in any API.
 
 Suggest this kludge be documented as a temporary security measure
 with a specific termination date, e.g. Monday 6 February 2006
 to give app writers four years to fix their code
 after which the emergency broken kernel
 can be restored to normal.
 
 		Cheers
 			--Devon
 	 /"\
 	 \ /	 ASCII Ribbon Campaign
 	  X	  Help Cure HTML Mail
 	 / \
 
 Most C coders ignore error status anyway,
 maybe a clean UNIX system is a lost cause,
 still no excuse for the current DWIM hack,
 pure poison to allow UI kludges in the API,
 blurring the concept of success or failure.
 
 Date: Tue, 9 Apr 2002 11:02:55 -0700 (PDT)
 From: <nsayer@FreeBSD.org>
 
 Synopsis: secure mode bug
 
 State-Changed-From-To: analyzed->feedback
 State-Changed-By: nsayer
 State-Changed-When: Tue Apr 9 11:01:58 PDT 2002
 State-Changed-Why:
 This is not a problem with the code, but rather the documentation.
 I've asked for help in getting the man page fixed, but not heard
 anything back.
 
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=33904
State-Changed-From-To: feedback->patched 
State-Changed-By: nsayer 
State-Changed-When: Mon Nov 4 11:32:02 PST 2002 
State-Changed-Why:  
The code achieves the desired result of allowing small time deltas at high 
securelevels and disallowing large ones. The documentation in -current has 
been updated. The concensus that has been reached over the course of this 
PR supports this action. 

After MFC of this documentation patch, this PR will be closed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33904 
State-Changed-From-To: patched->closed 
State-Changed-By: nsayer 
State-Changed-When: Mon Feb 10 22:05:21 PST 2003 
State-Changed-Why:  
MFCed 

http://www.freebsd.org/cgi/query-pr.cgi?pr=33904 
>Unformatted:
