From owner-freebsd-security Fri Feb 13 15:19:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29976 for freebsd-security-outgoing; Fri, 13 Feb 1998 15:19:25 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from nash.pr.mcs.net (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29956 for ; Fri, 13 Feb 1998 15:19:11 -0800 (PST) (envelope-from alex@nash.pr.mcs.net) Received: (from alex@localhost) by nash.pr.mcs.net (8.8.8/8.8.7) id RAA15473; Fri, 13 Feb 1998 17:17:39 -0600 (CST) (envelope-from alex) Message-Id: <199802132317.RAA15473@nash.pr.mcs.net> Date: Fri, 13 Feb 1998 17:17:39 -0600 (CST) From: Alex Nash Subject: Re: Secure Linux patch (fwd) To: robert+freebsd@cyrus.watson.org cc: freebsd-security@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On 13 Feb, Robert Watson wrote: > BTW, in -current, has their been any thought to requiring that time > monotonically increase (as BSDI has done) while in securelevel > 0? With > appropriate use of single-user mode, xntpd, and ntpdate, this can be very > useful. FreeBSD already does this, although the check is against securelevel > 1: sys/kern_time.c revision 1.23 date: 1997/05/08 14:16:25; author: peter; state: Exp; lines: +215 -33 [...] Note that I picked up the securelevel > 1 check from NetBSD that prevents the clock being set backwards in high securelevel mode (this was a hole that allowed resetting of inode access timestamps to arbitary values) Alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message