"The Linux Gazette...making Linux just a little more fun!"


(?) The Answer Guy (!)


By James T. Dennis, [email protected]
Starshine Technical Services, http://www.starshine.org/


(?) Alternative Method for Recovering from Root Password Loss

From David C. Winters on Mon, 14 Dec 1998

(?) Just discovered the LG, and your column, today. I sent you a message a few minutes ago asking a question; here's a submission.

You finish up your "No Echo During Password Entry" answer in your Issue #35 column with a method for recovering from losing root's password. I've used another method, using LILO.

During boot, when the "LILO boot:" prompt appears, hitting the <TAB> key will give you a list of all of the kernels (by label) that LILO knows about. On my system, I'd see

> LILO boot:
> 2.0.30		2.0.30-orig
> boot:

("2.0.30-orig" is the default Red Hat 2.0.30-3 kernel on 4.2; "2.0.30" is the label for the kernel I compiled.)

If I append " single" to a kernel label, eg, "2.0.30 single", it'll boot using that kernel but come up in single-user mode. Just calling passwd() will let you change root's password. You then want to use exit() to continue bringing yourself back up to your normal runlevel (3 on my machine).

(!) I'm well aware of this technique. However, using 'init=/bin/sh' will work in cases where 'single' won't.
Some systems have their 'single user' mode entries in /etc/inittab set to call an 'sulogin' command --- which requires a root password. Ooops!
I glossed over the details due to my own time constraints.

(?) Useful, but a large security hole. Unless you secure it, anyone sitting down on console can reboot the machine and come up as root. To close this hole off, chmod() /etc/lilo.conf to 600 (or 660 if it's owned root:root) and add the "restricted" and "password=<some_password>" lines, like the following example /etc/lilo.conf file:

(!) Quite right.
(?)
 boot=/dev/sda
 map=/boot/map
 install=/boot/boot.b
 prompt
 timeout=50
 restricted
 password=AnswerGuy
 image=/boot/vmlinuz
         label=2.0.30
         root=/dev/sda2
         initrd=/boot/initrd
         read-only
 image=/boot/vmlinuz-2.0.30-orig
         label=orig
         root=/dev/sda2
         initrd=/boot/initrd
         read-only

Run lilo(), then reboot. Entering "2.0.30 single" will get you to a password prompt. When you enter "AnswerGuy", the LILO password won't be echod to the screen as per normal for entering passwords, and LILO will bring you up as root.

This obviously requires remembering yet another password, but it's something to look into because, by default, LILO isn't password-protected on the Debian or Red Hat distributions I've used.

(!) Also quite right.
The principle problem with this is that it doesn't prevent the user from booting from a floppy (such as a Tom's Root/Boot (http://www.toms.net/rb) or even just an MS-DOS diskette with a disk/hex editor).
Some PC's have the ability to "lock out" the floppy drive and protect the CMOS with a password. That helps. However, it isn't much help. Many (possibly most) BIOS/CMOS sets have "backdoors" such that their support technicians can help customers "get back into" their systems. This is a bad idea --- but seems to be pretty common. In addition it's possible to open the system case and temporarily remove or short (with a resistor) the battery on the motherboard, or remove the clock chip (where the CMOS data, including the password, is stored).
So, to achieve any semblence of console security you must at least do the following:

(?) Debian: Whatever version was current two years ago; we switched to RH. Red Hat: 4.2

D.

(!) Thanks for the prompting.
I personally like the design of the Corel Netwinder (StrongARM/RISC based "thin clients" or "network computers" with embedded Red Hat Linux and KDE), and the Igel "Etherterm/Ethermulation" (PC based X Terminal, thin client, and character mode ethernet terminals, with custom embedded Linux --- and Java, Netscape and other optional tools on solid state disks).
Corel Computing, a division of Corel Software, Inc:
http://www.corelcomputer.com
Igel USA:
http://www.igelusa.com
These systems are specifically designed with no support for removable media. This makes this much better suited to deployment in hostile user environments (such as libraries, kiosks, Internet cafes, public access and college computing labs).
It is unfortunate that these systems are currently a bit more expensive than similarly powered PC's. Since they are currently produced in somewhat volumes and they are currently niche markets, they command a higher margin and don't benefit from the full economies of scale.
However, that's the main reason I don't own any of these.
(Another advantage to these systems, over and above security, is that they offer much less power draw and much quieter operation than standard PC's with that incessant fan and disk noise).


Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 36 January 1999


[ Answer Guy Index ] a b c 1 2 3 4 5 6 7 9 10 11 12
15 16 18 19 20 21 22 23 24 25 26 27 28
29 31 32 33 34 35 36 37 38 39 40 41 42 44
45 46 47 48 49 50 51 52 53 54 55 56 57 60 61 62 63 64 65 66
67 69 72 76 77 78 79 80 81 82 84 85 86 87 91 94 95 96 97 98


[ Table Of Contents ] [ Front Page ] [ Previous Section ] [ Next Section ]