Logging of all user activities

[Thomas Tuerler]

Is anybody aware of a solution to log all user activities. It should:
- be easy to check logs
- be easy to configure / maintain
- not be obvious to the user ( root )
In our environment, the user is not allowed to login as root directly, a group of admin users has the privilege to su to root. Login is done either with ssh or cde, no telnet, no r-commands.
Currently we have implemented a solution which has a .sh_history file for every user ( which becomes root ), but this is not accepted by the security audit dept due to the weakness that every user can easily modify his own sh_history file.

[Andreas Voss]

Hi,

to log ALL I/O you could add the command:
exec script
into the $HOME/.profile to save this informations.

Regards

[James R. Ferguson]

Thomas:

While 'script' (see man pages) doesn't meet all your criteria, it may be a start or at least a piece for you.

...JRF...

[Stefan Farrelly]

Switch on audting. Only secure detailed way to monitor all activities.

[Alan Riggs]

Quite frankly, there is no way in native HP-UX to log user activities that fulfils all of your requirerments: easy to view, easy to maintain, secure from alteration by folks who can become root.

Auditing will give you good information, as will having sessions script-ed, but both of these solutions create files which a rot user can modify. I know of at least one 3rd party security solution which interposes itself between the kernel and the shell and can be used to restrict the permissions of even the root user, but I do not recommend it for use in a csae like this.

Frankly, if you cannot trust the users you give root authority to, then you have deeper problems.

Perhaps you should examine sudo. It allows you to give access only to specific commands with root authority, and automatically logs all such activity.

[Rick Garland]

Doing the auditing or script will do what you are looking for. But the process is very expensive in terms of HW and I/O. All activity is logged to disk so you can browse through the logs but that takes disk space. In a small shop that may not be a concern but in a large shop, this could be a down-side.

[Ken Robson]

Well my, my, what a bunch of well thought out answers! The basic problem you face unless you use kind of MLS option is that the user is root, therefore anything that you do can be changed by them, its a bit catch 22 really. You could write your logs across the network to an NFS device that does not allow root access, this raises the bar a bit, however in most environments root could simply su to the user that owned the auditing information and then change it, however if the admins that you wish to audit do not control your naming service this becomes more difficult, but hey then they can just change /etc/nsswitch.conf and use the local file! So as you can see this auditing is a difficlut subject before we even get on to how to audit them (surely running script was a joke? You would have to exec script to stop the user from exiting out of it and as soon as you exec it you lose your environment - duh).

The only way to do this kind of thing is to use a MLS version of UNIX, I beleive trusted system mode implments this, in this scenario you have permissions applied to system calls in the kernel, you have one user who is root and the hold all the cards apart from the right to assign kernel permisisons and alter the audit information, the other user (formerly known as your security officer), can assign kernel level priveledge and alter the audit information.

Hope this helps.

[Paula J Frazer-Campbell]

Hi
Do these admin users have free roam of the system or do they just do specific tasks.

If the later then sudo or restricted sam can keep them under control.