.bash_history

Question for all sysadmins.
How do you keep track of what commands each user uses on his account. I thought an easy way is to monitor .bash_history, however those files can be "edited" by the user.
Is there a permission combination that will allow the shell to record to it but yet they can't edit it.

Thanks!

You can use process accounting... check the man page for accton for more details.

You can't really have a person updating a file like .bash_history and then disallow them to edit it (both actions require write premissions). Unfortunately Unix doesn't have as finely granuated file permissions as some other OS's. If you need to audit users activities you need an accounting program that logs targeted activities.

As a suggession perhaps you could run a cron job from root every minute or so to copy any changes to the .bash_history files to a secured directory. I haven't done this personally but it seems feesible.

Well, what if the user did this:

mv .bash_history .junk; ln -s /dev/null .bash_history

If the directory was writable, you may be able to do this even if the file wouldn't normally able to do this...

Also, if the user made that a hard link, the cronjob would always copy a null file...

Also, bash will usually not write out the history until the log out of the shell...

accounting is the best thing I can think of...

Certainly points to the accounting solution once again, espcially if you have a savy user who knows he is being monitored in this way. Of course, the user would need to suspect that he was being monitored in this way, but sometimes what seems unlikely happens and I can see this taking place.

History is certainly useless since it's under control of the user. I looked in my bash book at saw:

And there are many other ways to defeat history including typing "sh" and running a bourne shell for awhile.

I hate to be a party pooper, but accounting is also easily defeated. But why bother? Suppose your accounting records shows that I did:

vi perderabo.c
cc perderabo.c -o perderabo
./perderabo
rm perderabo.c perderabo

OK, now what did I do?

Some versions of unix have C2 level security features. You can configure them to track every system call invoked by every user. This puts a nasty load of the system though. Short of this, you aren't going to be able to reliably track what users do.

Hmm,...maybe I'm missing something here, but if you don't want your users to edit that file, why not just change ownership of the file to root, allow read and execute access only.

Just an idea.

VJ

It's not an excutable file. It's a text file so you need to be able to read and write to use it as a history file.

jason6792,

Search for under my name, Kelam_Magnus, and look for history answers.

I have a script that will help you keep track per user and you can chmod on the history file that is created.

:cool:

This is a very old thread, but if you want to keep the user from editing the .bash_profile, you might have a few options. In the /etc/profile, you might set HISTFILE, HISTSIZE, HISTCONTROL, HISTFILESIZE, HISTIGNORE, histchars, and any other history-controlling variables I might have missed as read-only, then "chattr +a ~user/.bash_profile". Then again, there is the situation described by Perderabo, in which someone writes a script, C, or any other program, and executes it, or just executes a shell. Also, the logging of all calls creates a tremendous amount of data to pour through, and will probably become neglected unless you have lots of free time on your hands.

If you don't trust your users, don't let them in. Otherwise, strengthen your boxes against attackers and hope for the best...

The way to proceed is to develop (or use exisiting) a wrapper program around the user login that logs all standard-in from keyboard, and logs this information securely so the user cannot modify.

I wrote a C program called 'keylog.c' that does just this for an HP-UX platfrom that did some very critical transactions and had users logging in from all over the world to debug real-time and near-real time errors.

The program basically wrapped around the user shell and logged all the keystrokes, with timestamps a the beginning of the login session and one at the end, of the user. The process could be killed by the user, but if a use attempted to kill the logging program, the program trapped the kill signal and would kill all child processes. If you can imagine this, this means that the user killed or attempted to kill the logging program, the user would be immedately logged out because his shell would die immediately.

BTW: None of this is performed with HISTORY and other shell functions. These are not reliable and were not designed for security, tracing nor auditing.

Worked great and the platform received insurance certification from LLoyds of London, which meant that enough security controls were in place to reasonably insure (not perfect, but good enough to insure combined with other controls).

I disagree with an earlier comment that 'if you don't trust users, don't let them login'..... they are simply too many production servers that require tracing and logging. Trust is relative and most mistakes that cost companies the biggest money are not from malicious activities, they come from well intended users who make honest mistakes. Those user makes must be traceable (to the user) and auditable in many applications.

(BTW: None of what I describe above is accomplished with shell history files like .sh_history, etc. Those files are not designed for real security applications.)

I definitely see your point, but I see a lot of admins who want to "spy" on their users, or a company that does not hire qualified or trustworthy personell. That is where I get my stance.

Being that I am currently working with a company that does demand real-time transactions and reporting 24x7x365, I understand that sometimes "mistakes" are made when trying to quickly solve a production problem, although in a working business they should be minimal.

In my limited experience, I have seen far more cases of hardware failure than "user error". A good case might be a grossly incompetent DBA whose database design is falling in on itself. And if he accidentally drops a critical index on the box, there's a good chance that most people aren't going to see that logged anyways in a typical setting, because many DBAs use tools like SQL Analyzer, or one of the Oracle front-ends... So do you sniff the wire? And where do you store this growing amount of information in a secure manner? Who analyzes it? Is this person authorized to have the various passwords and private information that they are bound to see in these logs? What is the retention policy on it?

I guess I just believe that if you're still trying to figure out how to keep a user from deleting their .bash_history, you probably haven't given this a whole lot of thought or planning in the first place. Nor would you likely have company backing, as this does become a legal privacy issue, if someone is let go for something you saw in this log.

Hmmm.

Yes, I tend to agree. If an admin's 'toolkit' of IT security options is via shell history files, then they have a long way to go......

On the other hand, we are here to guide them on the path.

It is a bit hard for folks with limited experience to see all the options AND they may work in an environment with limited resources to collaborate on these issues.

There are many legitimate system adminstrators with mult-user systems where accountability is critical to the mission. This is not 'spying' on the users because the systems are IT resources that belong to the company and the actions of users on those systems often require accountability. This is always true when the system application is insured, requires certification, and a myriad other professional operational IT system requirements.

Are we off topic yet? :slight_smile: