The danger of software suspend on servers

October 6, 2009

One of the interesting things about modern servers is that they often have the same sort of power-save support that desktops and laptops have, including the ability to be suspended in various ways. Usually this is harmless, but I am not convinced that it's a good idea in general. So, here's an amusing story to show why I feel that way.

We have some number of LTSP based X terminals that run regular X sessions on our collection of general login servers. This being the modern world, these sessions are full Gnome (or KDE) ones, and look pretty much like they would on a desktop machine (this is not always a great thing, as there are a number of applets and programs that make no sense on remote displays but don't notice this).

Once upon a time, relatively recently in fact, a user was logging out from their LTSP Gnome session and picked 'suspend' from the options menu. And, well, the machine did, because the server was capable of it and the software was willing to give it a go. Fortunately it was our least important and least used login server.

(For bonus points, the user did this on a Friday night.)

Now, part of how this happened was our slipup for not configuring Gnome to disable that particular feature (although, frankly, I blame Gnome for defaulting to allowing a remote session to suspend the machine). But part of it was because modern servers can be suspended, despite this not necessarily making a lot of sense.

(For extra amusement value, we almost didn't notice that this was what had happened, because when we came in on Monday morning it looked like the machine had spontaneously powered down so we just hit the power button and went on our way. We only clued in when we noticed an unusually large uptime for a machine that had been powered on that morning and then looked at the kernel logs.)


Comments on this page:

By Dan.Astoorian at 2009-10-06 14:37:56:

[...]I blame Gnome for defaulting to allowing a remote session to suspend the machine[...]

I would blame pm-utils (or its configuration), for allowing the hook that GNOME uses to work from a remote session to work.

I don't know about the distribution(s) you use, but on ours, /etc/pam.d/pm-* requires pam_console.so, so remote users should not be able to suspend a machine.

I would speculate that either your distribution is configured differently, or whatever protocol you use for your LTSPs make the sessions appear to be local sessions rather than remote.

FWIW, we set DISABLE_HIBERNATE="yes" and DISABLE_SUSPEND="yes" in /etc/pm/config.d/ on our lab workstations as well as our timesharing server, to prevent users from accidentally suspending the machines even from the console. (This didn't remove "Suspend" from the GNOME system menu, but it prevented it from successfully suspending the machine. Removing the option from the menu required setting the gconf key /apps/gnome-power-manager/can_suspend or /apps/gnome-power-manager/general/can_suspend, depending on the version of gnome-power-manager, to false.)

--Dan

By cks at 2009-10-07 12:52:17:

This happened on an Ubuntu machine; it doesn't seem to have anything in /etc/pm/config.d/ or any PAM modules to control power management. We had to change the settings in Gnome.

(Presumably there is a lower level lurking around somewhere, but I have no idea how to find it.)

By Dan.Astoorian at 2009-10-07 17:10:13:

See pm-suspend(8). Settings can go into any file in /etc/pm/config.d/. Of course, that assumes that pm-utils is ultimately the underlying mechanism by which the machine gets suspended.

The PAM stuff I referred to looks like a RedHatism; on RHEL5, /usr/bin/pm-suspend is a link to the normally-setuid-root consolehelper, which is what uses PAM to decide whether you're allowed to run it or not.

I don't know for certain what mechanism Ubuntu uses to accomplish the privilege escalation necessary to be able to suspend the machine, but I would guess that it sends a dbus message to hald, which ultimately runs an appropriate /usr/lib/hal/scripts/hal-system-power-* script (which may use pm-utils as the means to actually perform the suspend).

I have no idea what access controls hald might enforce, but I suspect that taking "Suspend" out of the GNOME menu probably just hides the trigger rather than disarming the weapon.

--Dan

By cks at 2009-10-11 02:16:26:

This happened on an Ubuntu system; Ubuntu appears to be charmingly under-documented for this sort of stuff, at least as of Ubuntu 8.04, and different from Red Hat.

(If we care enough, I see a great deal of reading about HAL, DBus, and all of that stuff in my future.)

Written on 06 October 2009.
« The problem with security bugs is that they aren't bugs
A brief introduction to ZFS (disk) GUIDs »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Oct 6 00:01:02 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.