thanks! [was Re: shutdown user and accountability]
-----BEGIN PGP SIGNED MESSAGE-----
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
shutdown:x:1000:1000::/tmp:/usr/local/sbin/shutdown
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
shutdown:x:0:0::/etc/shutdown:/etc/shutdown/shutdown
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
sync
sync
sync
sleep 3
/usr/sbin/shutdown -i0 -g0
fi
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/>
iD8DBQE8FY+RFsfyfWvjfZARAl79AJ9dl/klAaeBF3dpm7IhUE1lG1FLXwCcC8EK
udWwBZsyQAsDaVNVEpt3Yh0=
=tMSt
-----END PGP SIGNATURE-----
Reply to: