UNIX for Advanced & Expert Users

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.

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?