Sudo approach to HIST file

[MohitAnchlia]

In one of my earlier posts for auditing user sessions, somebody suggested following:

"You may also want to consider a 'sudo' approach to the user's history file so that he/she does not have direct write access to it. Routine archiving of ~user/$HISTFILE would also be a good idea"

Could somebody help me understand how can I do what has been suggested.

[Jaime Bolanos Rojas.]

MohitAnchlia!

When using sudo, you can tell which users can executed or have privileges under what, it also keeps a track of the actions performed by that user.

For more information regarding sudo, the oficial page is better:

http://www.gratisoft.us/sudo/

Regards,

Jaime.

[MohitAnchlia]

Putting it in my context could you please give me an example. I looked at the manual and it looks like you can just specify commands that user can run as super user.
But how does it solve my history file problem

[Mel Burslan · Accepted solution]

I am not sure who said that sudo approach to the history file but in the context it was used, it is not the right suggestion. A user's history file should be writable by the user and only the user to accumulate the commands he/she executes for future recall. If you yank the write privilege from the user himself, how is his shell be able to write to it ?

The meaning would be somehow different but I can not think of one off the top of my head.

[Jaime Bolanos Rojas.]

MohitAnchlia,

This old thread talks exactly the same that Spex was talking before.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=20355&admit=-682735245+1157999042402+28353475

Probably. The only thing that people wanted was to protect the history somehow.

Regards,

Jaime.

[James R. Ferguson]

Hi:

I agree with Mel. If I (my shell) can write to its history file, then I (as a user of the shell) can simply truncate (> .sh_history) if I want to obliterate my history.

Regards!

...JRF...

[Mel Burslan]

very cpu intensive and disk utilization heavy way of doing this, while logged in as root or equivalent

before starting the procedure,

for home in `cat /etc/passwd | awk {'print $6'}`
do
if [ -a ${home}/.sh_history ]
then
cp ${home}/.sh_history ${home}/.sh_history.sav

else
touch ${home}/.sh_history.sav

fi
chmod 400 ${home}/.sh_history.sav
done

while true
do

for home in `cat /etc/passwd | awk {'print $6'}`
do
if [ -a ${home}/.sh_history ]
then
histsize=`cat ${home}/.sh_history | wc -c`
savhistsize=`cat ${home}/.sh_history.sav | wc -c`

if [ ${histsize} -ne ${savhistsize} ]
then
cp $home/.sh_history.sav .sh_history.sav.`date | sed -e "1,1s/ //g"`
cp ${home}/.sh_history ${home}/.sh_history.sav
fi
done # done executing the for loop

sleep 30 # wait 30 seconds or adjust according to your desires

sone #done executing while loop


include
BEWARE : This is a concept. it has not been tested for neither syntax, nor logic. If you are planning to use it, test on a small set of data. In case it works, accumulation of history file logs may cripple your system and heavy looping may cost you a very bad performance penalty.

[spex]

Hi,

When I made that statement, I was suggesting a sudo-like approprach of preventing direct access to .sh_history (sh & ksh) and .history (csh). I wasn't implying that using sudo is the way to accomplish this.

Notice how user1's command history continues to be recorded even after .sh_history gets mode 400:

$ whoami
user1
$ pwd
/home/user1
$ ls -al | awk '{print $1,$3,$9}'
total
drwxr-xr-x . user1
drwxrwxrwx .. root
-rw------- user1 .Xauthority
-rw------- user1 .sh_history
$ echo "uno dos tres"
uno dos tres
$ tail -2 .sh_history
echo "uno dos tres"
tail -2 .sh_history
$ chmod u-w .sh_history
$ ls -al | awk '{print $1,$3,$9}'
total
drwxr-xr-x . user1
drwxrwxrwx .. root
-rw------- user1 .Xauthority
-r-------- user1 .sh_history
$ echo "cuatro cinco seis"
cuatro cinco seis
$ tail -2 .sh_history
echo "cuatro cinco seis"
tail -2 .sh_history

In fact, history is still recorded even after .sh_history gets a new owner and group:

$ chown root:root .sh_history
$ cat .sh_history
cat: Cannot open .sh_history: Permission denied

As root:

# tail -2 ~user1/.sh_history
chown root:root .sh_history
cat .sh_history

However, user1 can still delete .sh_history:

$ rm .sh_history
.sh_history: 400 mode ? (y/n) y
$ ls -al | awk '{print $1,$3,$9}'
total
drwxr-xr-x user1 .
drwxrwxrwx root ..
-rw------- user1 .Xauthority

so it's not a perfect solution.

PCS

[MohitAnchlia]

So except turning the server to trusted mode there is no other way to track User commands ?

[Steven E. Protter]

Shalom,

It is NOT necessary to go to trusted mode to track user commands.

Merely setting the HISTFILE variable to a non-nfs location in the user profile will track user commands.

Note that a smart user can obliterate his .sh_history file. I know of some schemes were a cron job sweeps all of the .sh_history files to a backup location so that discrepencies can be spotted.

To prevent endless history files, set the HISTSIZE variable.

Also, since you are a new user to ITRC, let me inform you that if any of the answeres here were of assistance, that you are encouraged to assign points to those answers.

Regards,

SEP

[MohitAnchlia]

Could you please elaborate little more on setting HISTFILE to non-nfs location. How do I do this and how will it help?

[Pete Randall]

An example for non-nfs history file - in /etc/profile:

HISTFILE=/tmp/.sh_history.$(whoami)
export HISTFILE

Note the location refers locally rather than to some NFS mounted locale like "HISTFILE=/nfs/srvr1/home/user_name".


Pete

[spex]

In ~user/.profile:

HISTFILE=/tmp/.sh_history.${USER}.${$}
export HISTFILE

Doing this only makes $HISTFILE more difficult to find for the user. It does not prevent him/her from altering/deleting it.