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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970728212044.26892I-100000>