.sh_history security

[TheJuiceman]

Hello all,

What is the best way to disable users from being able to delete their own .sh_history? Thanks

Bob

[Biswajit Tripathy]

If the user has permission to write to the file, then it
will be able to remove lines from the file. I'm not sure
how will you stop that. If you want to track all the
commands user is using, you need to come up with
another solution.

- Biswajit

[TheJuiceman]

Thanks. I have scripts to record sh_history for our security admin. But I want to eliminate the temptation from savvy users from deleting their sh_history if they do something wrong, maliciously or not. Any thoughts?

Thanks.
Bob

[Biswajit Tripathy]

I personally have never used this, but I think you
could turn on Auditing on the system that would
record all important user activities.

See:
http://docs.hp.com/en/5990-8172/ch08s09.html

- Biswajit

[A. Clay Stephenson]

First of all, the ability to delete a file is controlled not by the permissions of the file itself but rather by those of the directory. It's not practical to allow someone not to able to write to their own home directory. Your could define HISTFILE in /etc/profile to be a non-standard location but still the user would have to be able to write to the file for it to serve any purpose. As has already been stated, a user thus has the ability to alter the file. You are trying to use .sh_history for a purpose that it was never intended; it's reason for being is command re-execution and editing not security. Accounting might come closer to meeting your needs but security isn't its function as well but you would get a record upon every process termination.

[Nguyen Anh Tien]

Hi Bob
This is my solution
1. adding this line to the end of /etc/profile or /root home directory/.profile
#vi /etc/protile
.....
.....
HISTSIZE=0
export HISTSIZE
2. remove old history file (.sh_history) and Log out
#exit
3. Log in.



for more you cat get at:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=247729

[TheJuiceman]

Hi everyone,

Thanks for the responses. But maybe I should try to make more clear what I want to accomplish....

I know that the .sh_history was not intended for implementing security. I also am not wanting to keep people from writing to their .sh_history files.

I am wanting to use the .sh_history for better tracking purposes. But, this is ineffective if the user can simply rm their file. I am just trying to find a way to make it impossible for a user to rm any .sh_history file. Is there something I can put in their .profiles? Or make a link to the rm command to a script that will not allow an rm of a .sh_history? Something like that. I have made links to the shutdown command that will display a warning and confirmation message before the system can be taken down (this has been handy a few times when an admin thought they were taking down a system, but were on the WRONG system). Any help you can offer is appreciated.

Thanks,
Bob

[TheJuiceman]

PS - Oh, and I should mention that due to some software issues, I cannot go to a trusted system. Thanks again.

[A. Clay Stephenson]

You don't want to put it in their .profiles because they can easily change it. What you want to do is set HISTFILE in /etc/profile.

if [[ "${LOGNAME}" != "root" ]]
then
HISTFILE=/xxx/yyy/${LOGNAME}.hist
export HISTFILE
fi

Now, make this directory only writable by root and create a null file (or copy their existing .sh_history file to) /xxx/yyy/${LOGNAME}.hist. You need to create a file for them because they can't write to this directory BUT they can update an existing file in this directory. It's still not foolproof because they can always edit this file and I'm also unsure of the shell behavior when it needs to truncate the history file. I really don't like this because the file can be edited and any security file I have to ask "it it trustworthy" is by definition not.

[Biswajit Tripathy]

Ofcourse, you should be aware of the fact that,
whatever you set HISTFILE to and whether you
set it in /etc/profile or user .profile, the user can
always unset HISTFILE, execute commands (s)he
does not want to be written to HISTFILE and reset
the parameter HISTFILE again. You will have no way
of finding it out.

- Biswajit

[Biswajit Tripathy]

Bob Socall wrote:
> I am just trying to find a way to make it impossible
> for a user to rm any .sh_history file. Is there
> something I can put in their .profiles? Or make a link
> to the rm command to a script that will not allow an
> rm of a .sh_history?

But the user can always go around that. Like, for ex,
"mv .sh_history tmpfile" and "rm tmpfile". Or just use
good old vi to delete all the lines in the file, there by
making it useless for you even if (s)he can't delete the
file.

- Biswajit

[Mic V.]

Some random ideas:
- possibly use the "script" command somewhere
- any way to exclude their shell access? (I don't know what their jobs require -- I'm thinking SAM, a restricted user that can only run sudo, something like that)
- create a custom shell that does something different with command input -- such as logging it to syslog

HTH,
Mic

[Gordon Morrison]

Another idea might be to edit /etc/profile so that it creates a hard link (NOT a symbolic link!) to each user's .sh_hist* files to another directory, owned by root, with 733 permissions. That way they will be able to write to it, but won't be able to see the contents, so they would need to know the exact name of the file. then be sneaky about what you call it.

Something like this in /etc/profile

HISTFILE=.sh_hist$$;
ln $HISTFILE /secret/${HISTFILE}.$(whoami)

Maybe put the date in there as well:

HISTFILE=.sh_hist$$;
thedate=`date +%C%y%m%d%H%M%S`
ln $HISTFILE /secret/${HISTFILE}.${thedate}.$(whoami)

You'd also have to make sure that /etc/profile is readable only by root, or they'll be able to work out the filename and delete it.
(rm /secret/* won't work, but if they know the filename, they can delete it)
Any savvy user is bound to eventually notice the "2" in the number of links column in the ll output, but without the exact filename, (or the root password) they can't do anything about it.

[Mark Nieuwboer]

Hi,

All of the above is still not working.
Only when the home directory of the user is not own by it's own user .profile can't be changed. If not the user can always change there .profile and escape your auditing.
Only an external programe such as pentasave you can monitoring the user behavior.

grtz. Mark

[Gordon Morrison]

Biswajit wrote:
>Ofcourse, you should be aware of the fact that,
>whatever you set HISTFILE to and whether you
>set it in /etc/profile or user .profile, the user can
>always unset HISTFILE, execute commands (s)he
>does not want to be written to HISTFILE and reset
>the parameter HISTFILE again. You will have no way
>of finding it out.

Not if you do:
HISTFILE=whatever
readonly HISTFILE
export HISTFILE

in .profile or /etc/profile

Of course, this only works for ksh & Posix

[Gerhard Roets]

Hi bob

Well ... by definition a user should be able to modify their histfile ... so that implies a "> histfile" would always clear it. So for the technically savvy user the way to negate this would be quite simple.

System auditing on a trusted system would most prolly be the way to go.

HTH
Gerhard