Setting Access Rights

[Glauco Sesta]

Hallo.
Could anyone please tell me how to set access rights to a history file, so that you can append logged commands to it but NOT edit or delete it?
Can ACL's help me out on that?

The reason I need that is I have a user causing some trouble on the system and want to identify him by logging his IP address (different physical persons log in as that user, which is why I need to log his IP address).

Thanks.

[Peter Kloetgen]

Hi Glauco,

did you try to change owner of that file using chown- command? Or do a copy of that file into another directory which is not owned by that user with a cronjob.

Allways stay on the bright side of life!

Peter

[V. V. Ravi Kumar_1]

hi,

use
last -R |grep
to identify from which IP that user is logging in. then use
lastcomm -u
compare the login time with the previous command and u can identify which command he used. to get out put from lastcomm u should enable accounting on ur system. see man page accton.

regds

[James R. Ferguson]

Hi:

I think you are referring to 'var'adm'wtmp' in which case, its permissions should be 644. The appropriate way to empty it is to redirect /dev/null into it, as :

# cat /dev/null > /var/adm/wtmp

This preserves the current ownership, permissions and any open file descriptors, allowing new and current processes to write to the same file.

Regards!

...JRF...

[Christophe MAILHE]

Hi Glauco,

You could try to set the following variables in the user profile :

CALLINGHOST=`who -R | cut -d"(" -f2 | cut -d")" -f1`
HISTFILE="$HOME/.sh_history-$CALLINGHOST-$(date +'%Y%m%d%H%M')"

The historic file for the user will be moved to the file defined above and you should be able to trace who is doing what.

Christophe.

[Edgar Matzinger]

Hi Glauco,

you could use the accounting routines HP-UX has, as others have stated. But these give you only the commands the untrustworthy uses, but not the arguments. Because what you want is not possible. And if you have a knowledgeable user, than all he has to do is to "unset HISTFILE" and no history is logged.
If you are really paranoid/worried, you can always download the source of a shell (like zsh), and adjust that to log the commands entered to a file outside the reach of the perpetraitor. And repeat this for all the shells you/they use.

HTH, cu l8r, Edgar.

[Glauco Sesta]

Hello Edgar,
your reply is the one that most got the point.

Unsetting a variable is impossible if the variable is set like this:

# readonly CALLINGHOST=`who -R | cut -d"(" -f2 | cut -d")" -f1`

I and a colleague are setting up a complicated thing that goes like this:

We've put the following in /etc/profile

IP=`who -Rm | cut -d"(" -f2 | cut -d")" -f1 | cut -d: -f1`

data=`date +%a%d%b%y`
control=`whoami`
if [ ! -d /var/tmp/history ]
then
mkdir /var/tmp/history
chmod 1777 /var/tmp/history
fi

if [ $? -eq 0 ]
then
if [ ! -d /var/tmp/audited-history ]
then
mkdir /var/tmp/audited-history
chown -R root:sys /var/tmp/audited-history
fi

readonly HISTFILE=/var/tmp/history/???sh_history_${control}_${data}_${IP}
readonly HISTFILE2=/var/tmp/audited-history/???sh_history_${control}_${data}_${IP}
readonly HISTSIZE=400
export HISTFILE HISTSIZE HISTFILE2

# nohup tail -f $HISTFILE >> $HISTFILE2 &
fi

That means individual history files are created in /var/tmp/history called sh_history_USERNAME_DATE_IP-ADDRESS.

Those files, though, have user read and write permissions.
Which means the perpetrator can read/modify/delete it.
Inserting ^X before the filename is a lame measure that won't fool an experienced user.

What we're working on is a sort of daemon (script launched by root's crontab) that tails -f all files in /var/tmp/history and appends (tail -f histfile1 >> histfile2) them to a place where they're safe from non-root editing/deleting.

Anybody have faced this problem before?
Thanks for all the answers.

Glauco

[Wodisch_1]

Hi Clauco,

if you are about to create and setup a daemon, then why not write your own PAM module?
With Plugable-Authentication-Modules you could register your own module for TELNET (or whatever that guy is using) and inside this module you can do what you want...
Or you could turn your system to "trusted" (command /usr/lbin/tsconvert) and "audit" this user (hint: use SAM for this).

Just my $0.02,
Wodisch