Security - Root Account Shell History

[Henry Weldon]

How can we add date/time stamp information automatically to the shell history?

[Pete Randall]

Henry,

No way that I know of.


Pete

[john korterman]

Hi,
I do not think it is possible for the obvious reason that it would make the file useless for its original purpose, e.g. recalling a prevous command.

regards,
John K.

[Brian Bergstrand]

I don't think you can, the shell writes this history log, and I don't know of a way to tell it to time stamp the entries. There's a problem with this approach too: Anyone with root access can expurgate the file. So if you are trying to track commands, and someone doesn't want you to know, they can remove the entries.

A better way to do this, might be to convert to a trusted system and then enabling accounting for the root account. Then the system will then track every single command run by root and log it in a binary file format. Someone who knows what they are doing can edit this file too, but it requires specialzed commands to do so.

HTH.

[Jeff Schussele]

Hi Henry,

Nope, sorry there's no easy way to do this.
The history file is a binary file, but not just a run-of-the-mill binary file & this is deliberate so that any tampering will make the file unreadable. This is so one cannot cover their tracks without leaving a big clue.

One thing I could think of doing is every so often issue the following command
date | logger #110503080345
which history would dutifully store & the syslog.log would contain the date entry from the issuing user. You can use the syslog.log to verify the history entry.

My 2 cents,
Jeff

[Brian Bergstrand]

Jeff,

I just checked my .sh_history file, and it is plain text. (11.00) Are you sure your not thinking of the binary accounting files?

Also, with root access, syslog is not tamper safe either. Nothing is. Good idea about the logger though. You could also execute `date >> $HOME/.sh_history' every few minutes from cron. Doesn't fix the tampering problem though.

[Mark Grant]

This is a terrible hack but you could have a little script that get run by .profile, loops reading from the history file and writes out each line as it gets it with a time stamp to a completely different file.

[Graham Cameron_1]

You need a tool like upm (unix privilege manager).
http://www.passgo.com/datasheets/upm.pdf

-- Graham

BTW - .sh_history may not be a true binary file, but it's no ordinary text file - mine starts with 2 control-As.

[Jeff Schussele]

Hi Brian,

It's true that the file command will report the .sh_history file as ascii text.
But more it out & look at it. It will contain control chars placed at seemingly random intervals. But there is a method to this madness & this is what the shell uses to determine whether the file has been altered. Any editing of this file upsets this sequence & renders the file useless.
Try it if you don't believe me.

Rgds,
Jeff

[Geoff Wild]

Don't know if this helps, but everytime we su to root, we date stamp a "personal" history file. Basically, every sysadmin who su's to root has there own root history file.

For example, mine is .sh_history_gwild

In root's .profile, add:

# Set up logging
HISTFILE=${HOME}/.sh_history_`who am i|awk '{ print $1}'`
date >>$HISTFILE
export HISTFILE
HISTSIZE=500
export HISTSIZE

If you wanted to do it for every single command run as root - then you would have to write some sort of "wrapper" script for every command to be run as root - ouch....

Rgds...Geoff

[Thierry Poels_1]

Hi,

for admin accounts (root, dba, ...) we have a history file per user per terminal. This prevents you from retrieving someone elses previous commands (not really for security reasons, but more for safety : you don't want to execute someone elses command again by accident, specially not rm statements).

HISTFILE=$HOME/.sh_history_`basename $TTY`

This trick allows you also to put some extra info in the history file when they login : "who am i", "date" to get real user name and login time.

regards,
Thierry.

[Brian Bergstrand]

Jeff,

I noticed the control chars at the top, but didn't notice the rest. Anyway, just for s**ts and giggles I tried replacing a command in the history file with random characters ammounting to the same # as the original command. It worked. My history file was still valid, and fc still let me use it. So these control chars may protect against outright removal of a command, but not against replacement. I suspect it's not a tamper system, but more of an indexing one.