From owner-freebsd-security Mon Jul 28 17:11:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA15090 for security-outgoing; Mon, 28 Jul 1997 17:11:30 -0700 (PDT) Received: from thought.res.cmu.edu (THOUGHT.RES.CMU.EDU [128.2.94.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA15071 for ; Mon, 28 Jul 1997 17:11:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thought.res.cmu.edu (8.8.5/8.6.12) with SMTP id UAA27068; Mon, 28 Jul 1997 20:09:40 -0400 (EDT) Date: Mon, 28 Jul 1997 20:09:40 -0400 (EDT) From: Brian Buchanan To: Vincent Poy cc: freebsd-security@freebsd.org Subject: securelevel (was: Re: security hole in FreeBSD) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 28 Jul 1997, Vincent Poy wrote: > =)I was under the impression that doing a 'make world' in multiuser mode > =)wasn't optimal. > > I know but when all the admins are remote, it has to be done > multiuser. Is there a way to push the secure level up to 2 and then push > it down when a make world is needed? Uh, that would defeat the purpose of securelevel. It's not supposed to be possible to ever lower it, except when dropping into single-user mode, and even allowing init to do so in that instance is risky IMHO - a few months ago I reported a hole, which I believe was fixed, that made it possible to lower the securelevel by attaching a debugger to init. Even though that's plugged now, it's still possible that there's another way to fool the kernel into thinking that process 1 is requesting that securelevel be lowered.