[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

thanks! [was Re: shutdown user and accountability]

Hash: SHA1

Olaf Meeuwissen <olaf@epkowa.co.jp> wrote:

> I'm maintaining a (small-time) group server for our department.  In
> order to satisfy company policy requirements I need to provide a way
> to shutdown the server in case of emergencies.  Our network admin was
> kind enough to give me two alternatives:
>   1) provide an on-screen shutdown button
>   2) provide a shutdown user account (and document its usage)
> I didn't like either approach because they lack accountability: after
> a shutdown I can't tell *who* did it.
> BTW, the server has no screen for buttons, so 1) is not an option to
> begin with.  You have to ssh in to do anything (exploit one of inetd,
> exim, samba or apache in some way may be an alternative ;-).
> I came up with a 'sudo /sbin/halt' for department members (and others
> on an as needed basis), but that was no good.  Everyone has to be able
> to shut it down.  I racked my brains but didn't come up with anything
> that provides accountability.  Anyone any suggestions?
> Right now, I'm stuck with 2) and writing the password on the machine
> (or similar) *or* stay with what I have now and take my chances with
> people flicking the power switch.
> BTW, the server is not in a physically secure location, so I run the
> power switch thingy risk anyway.
> Suggestions, discussions of pros and cons welcome,

Thanks to everyone who responded.  I should have been a little clearer
on the system setup.  The machine in question consists of a main unit
and a bunch of externally attached hard disks connected to a network.
It has no monitor, keyboard (what Ctrl-Alt-Del?) and mouse.

As I already feared, it is impossible to provide a shutdown account
without giving up accountability.  Some pointed out (correctly) that
without physical security I didn't have accountability to begin with,
but I was wondering whether I needed to sacrifice it even further.

Some replies suggested I validate against a general database, e.g. for
Winblows logon (that'd be just about the only viable alternative in my
situation).  That could be a nice approach, but one would have to be
able to trust that database (and since it is not under my control ...
btw, I hope it stays that way, win-DoS shudder ;-)

The replies regarding journalling file systems reminded me of the fact
that I still have to look into those (especially since we have annual
thunderstorms occasionally knocking the power out).

I liked the camera idea!  If I get some time, I may give it a go.  We
have quite a few digital camera's around here and one on my machine
wouldn't look like an obvious security measure.

Finally, one reply mentioned that I would have the IP address logged
right before the shutdown because people that want to shut down the
machine have to ssh in.  Shame on me for forgetting that.

In the mean time, our network administrator seems to have seen the
light and now requires a shutdown account so he can shut the machine
down anytime he needs to.  With that I can live, so I provided one
where all he can do is shut the machine down.  Should he choose to
share the password, then that is his problem.

So, I've added a user along the following line


where /usr/local/sbin/shutdown (root.root 0755) looks like

  #! /bin/sh
  exec /usr/bin/sudo -K /sbin/halt

and added the shutdown user to the users allowed to run /sbin/halt in
my sudo setup.  I liked this better than another setup they suggested
at work (for a Solaris box) where they add a user as


with /etc/shutdown/shutdown (root.root 0744) looking like

  #! /bin/sh
  echo "Do you want to shutdown now? (y or n):   \c"
  read yn
  if [ $yn = 'y' -o $yn = 'Y' ] ; then
      sleep 3
      /usr/sbin/shutdown -i0 -g0
  exit 0

I didn't see any obvious flaws in the above script, but I disliked the
prompting and, what's more, the shutdown user has r00t privileges!

Anyway, thanks to all the paranoid folks who responded.
- -- 
Olaf Meeuwissen       Epson Kowa Corporation, Research and Development
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97  976A 16C7 F27D 6BE3 7D90
LPIC-2               -- I hack, therefore I am --                 BOFH
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/>


Reply to: