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:
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:
- Lock the PC in a cabinet, closet or case (or install one or more locking bolts in the case.)
- Verify that the BIOS has no back door (how?) or replace the BIOS with a custom one or one that has been audited and verified by some trusted party as having no back doors.
- Disable floppy and CD-ROM boot.
- Enable CMOS password protection to prevent changes to the boot and other CMOS settings.
Debian: Whatever version was current two years ago; we switched to RH. Red Hat: 4.2
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:
- Igel USA:
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).