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

Secure Shutdown from the Console

From Werner Ackerl on Sun, 28 Mar 1999

Dear jim,
I've been using Linux for - well, it must be four years by now, and I've finally got around to do my first donation to the community.

I'm a bit concerned about security - part of my tip is about creating a new user to run /sbin/halt - I just don't want to (re)introduce any hazard.

Would you please have a look a it? The text is attached.

thanks, werner

nb: My tip is intended to go to the 2-cent-tip column. I'll be glad to include your comments.

(Attachment includes a kernel patch to change the LED status on kernel halt, and some suggestions on create a user account with /sbin/halt as a shell, etc

This is all in the context of a print server in his closet that he wishes to run without the monitor attached most of the time. He also wants it to be shutdown down on a nightly basis due to the noise factor).

Werner,

I didn't attempt to do a thorough code audit of the attached file. However, I do have some ideas on how I'd attempt this.

First, I'd avoid a kernel patch. I might write a small small utility shell script that would cycle among the LEDs that might look something like:

#!/bin/sh
trap "/usr/bin/setleds -L" 0 1 2 3 5 6

while /bin/true; do
        setleds -L +num; setleds -L -num
        setleds -L +caps; setleds -L -caps
        setleds -L +scroll; setleds -L -scroll
        sleep 1
        done
setleds -L

... this just turns each keyboard LED on then off, in turn, waits one second and repeats the process. The -L causes the command to affect only the LED lit status and not the actual keyboard lock status. In other words this blinks the lights without actually setting the keyboard CapsLock, NumLock or ScrollLock settings. The extra 'setleds -L' and the trap attempt to resync the the LEDs to our actual keyboard lock status as we exit the loop and on any common form of interrupt signal. (The part outside the loop is non-sensical for this loop, with /bin/true as our condition --- but would make sense if we added some 'break' test inside the loop or changed the loop condition).

With that script set up I might invoke it via init (/etc/inittab) or from a startup script.

That gives me a constant indicator that the computer is still processing user space stuff. It should also tell me when the halt is completed (since the 'cycleleds' script will be killed only a few seconds before the rest of the system has been fully halted.

Instead of the special user in the /etc/passwd file (which might be remotely accessible) I'd just modify the line in /etc/inittab that refers to the /sbin/shutdown command. I'd change that line from something like:

ca::ctrlaltdel:/sbin/shutdown -r -t 4 now

... to:

ca::ctrlaltdel:/sbin/shutdown -h now

... and I'd then just use [Ctrl]+[Alt]+[Del] (the traditional PC "three finger salute" or "vulcan PC pinch") to do my shutdown.

[ I did this for my laptop, since I'm far more likely to do that in order to pack it away, than to need to to restart it. -- Heather ]

The advantage to this method is that it doesn't involve any login and that it absolutely requires physical access to the system to invoke (unless your attacker can employ telekinesis, of course).

A more elaborate method would be to write a small C program that issues the appropriate ioctl()'s to cycle the LEDs at your desired frequencies, and to have it monitor the keyboard for your custom key event. Have that started from /etc/inittab.

You could find out how to control the LEDs by reading the sources to the 'setleds' program (which is in the kbd or consoletools packages), and you read up on the shutdown() system call from its man page, or read the example in the sources to the 'shutdown' command.

There is a small package that's included with Debian 2.x that blinks your LEDs based on network traffic. There's also a utility called "loaddog" which is a system load watchdog. These are the sorts of things you might use on your system to monitor your system's activity without turning on the monitor and without connecting to it through your LAN from the other systems on your net.

Of course, if I had this system in my closet and I wanted to shut if off, I'd just have a script on my desktop system that would perform the desired operation over ssh. It's assume that the system was pretty well done with its shutdown by the time I got to it from my desk.

With newer APM motherboards you can configure you systems to power off on shutdown. I think this is possible even with desktop systems that implement APM features.

I'm not saying that there's anything wrong with your approach. However, it seems like more work and more risk than my method.

As for the noise. I can understand your concern. I have a number of relatively noisy computers around the house and am considering trading them out for quieter systems. It's ironic that these systems (like my trusty old 386s --- my router and my main mail, news and internal web server) are still electronically perfectly suitable for my workload and that the only reason I'm considering replacing them is to reduce the power consumption, heat generation, and noise emanations.

Luckily I have just enough load on my finances to resist the urge to buy couple of rackmounted Corel Netwinders and/or Cobalt Raq's. Those are both very quiet systems with much less fan noise than my current systems. I already have most of my current systems in a closet, with cables leading out to a switchbox, and thence to my keyboard and monitor.

One of my best customers has his cables poked through a wall between his den and the garage. That room is really quiet. unfortunately my house isn't laid out in a way that makes that feasible. The garage is by the kitchen and the den and bedrooms are all adjacent to one another.

As I get richer (or less thrifty) I'll probably get a couple of Igel (https://www.igelusa.com) X terminals or desktop Netwinders (https://www.hcc.ca) to use at my desk and in the living room.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 39 April 1999

	2	3	4	5	6	7	8	9	10	11
	12	13	15	16	18	19	21	22	23