From owner-freebsd-security  Mon Jul 28 18:25:52 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA21258
          for security-outgoing; Mon, 28 Jul 1997 18:25:52 -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 SAA21253
          for <freebsd-security@freebsd.org>; Mon, 28 Jul 1997 18:25:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by thought.res.cmu.edu (8.8.5/8.6.12) with SMTP id VAA27288; Mon, 28 Jul 1997 21:24:56 -0400 (EDT)
Date: Mon, 28 Jul 1997 21:24:56 -0400 (EDT)
From: Brian Buchanan <brian@thought.res.cmu.edu>
To: Vincent Poy <vince@mail.MCESTATE.COM>
cc: freebsd-security@freebsd.org
Subject: Re: securelevel (was: Re: security hole in FreeBSD)
In-Reply-To: <Pine.BSF.3.95.970728173307.3844R-100000@mail.MCESTATE.COM>
Message-ID: <Pine.BSF.3.96.970728212044.26892I-100000@thought.res.cmu.edu>
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:

> On Mon, 28 Jul 1997, Brian Buchanan wrote:
> 
> =)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.
> 
> 	Anything is possible since nothing is unhackable.  Would running
> init at securelevel 2 and then have it reboot multi-user at a lower level
> be possible?

That defeats it just the same.  The attacker breaks in, reboots the system
into multi-user with securelevel 0, removes schg flags, alters init, the
kernel, /bin/login, whatever, kills the logs, raises securelevel back to 2
to cover his tracks.  Allowing the securelevel to be lowered and the
system to return to multi-user mode without operator confirmation is a bad
thing - it completely defeats its purpose.  If it's not possible to do
maintenance at the local console, it's probably best not to use
securelevel.