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) Message-ID: <Pine.BSF.3.96.970728212044.26892I-100000@thought.res.cmu.edu> In-Reply-To: <Pine.BSF.3.95.970728173307.3844R-100000@mail.MCESTATE.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970728212044.26892I-100000>