From owner-freebsd-hackers Sun Sep 5 22:15: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 2AAE015443; Sun, 5 Sep 1999 22:15:02 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id PAA12402; Mon, 6 Sep 1999 15:13:48 +1000 Date: Mon, 6 Sep 1999 15:13:48 +1000 From: Bruce Evans Message-Id: <199909060513.PAA12402@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, kato@ganko.eps.nagoya-u.ac.jp Subject: Re: Init(8) cannot decrease securelevel Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Once securelevel has been increased, no process can decrease it because >kernel always refuse decreasing it. This is inconsistent with the >manual page of init: > > The kernel runs with four different levels of security. Any super-user > process can raise the security level, but only init can lower it. > >Is there any security problem to implement this? If no, could someone >review following patch? The patch just backs out rev.1.9: RCS file: /home/ncvs/src/sys/kern/kern_mib.c,v Working file: kern_mib.c head: 1.25 ... ---------------------------- revision 1.9 date: 1997/06/25 07:31:47; author: joerg; state: Exp; lines: +2 -2 Don't ever allow lowering the securelevel at all. Allowing it does nothing good except of opening a can of (potential or real) security holes. People maintaining a machine with higher security requirements need to be on the console anyway, so there's no point in not forcing them to reboot before starting maintenance. Agreed by: hackers, guido ---------------------------- There used to be security holes that allowed root to lower `securelevel' using init. Rev.1.9 defends against any undiscovered holes. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message