The only way to get what you are asking for is to replace the exec system call... but event that doesn't record everything - the damage may be done by using a perfectly valid program to do something that isn't authorized.
And expect so much output that your recording system fills up.
To "monitor RHEL servers" calls for actually monitoring them - apply SELinux rules to the files you want to protect, add auditing to record file accesses, deletions, process accounting, and actually review the logs.
When something goes wrong you will be able to find the login, and when it was done. Check out some of the inotify utilities (
https://github.com/rvoicilas/inotify-tools/wiki) to track specific files (doing this reduces the log rate, and can identify when something happened, though not who - that is up to different tools. But the library provided should be able to give hooks that can be used to extend the base information).
Does it work in all cases? No. It takes a lot of time to go through the logs, and it takes a lot of storage to save the logs. One system I worked on was shown to generate 17MB of logs every second (and that one only had 8 processors).
You also run the risk of violating various laws regarding either privacy or even secrecy... some of the information revealed by the logs may contain classified information (either military, government, or just company trade secrets) - so have a lawyer/security personnel/responsible manager that can authorize such activity (in my one case, my manager wasn't even authorized to know what I was recording - I was taking direction from an external security unit).
The problem with recording command lines is that it may record only a single command, with no parameters.
But that command may have the entire attack built in - with no additional commands involved. A simple "a.out" executable does the work. Any parameters required may be taken from the environment variables, and setting those doesn't require an exec. So recording an exec CAN include the environment... but expect each record to contain up to around 100K+ for the environment, and 100K+ for possible parameters... (see
http://www.kernel.org/doc/man-pages/.../execve.2.html for memory requirements for parameters and environment).
For most auditing/investigations, it is sufficient to have the pacct entries (the command name, and some of the parameters). Correlating the timing of the pacct records + knowing when the files are deleted (auditing/inotify tools) is enough. Sometimes it is desirable to record user sessions - even though such sessions cannot record internal activity (this can be done by a modified "tee" utility and modifying the login - usually sshd - to start the modified tee utility with the users shell as the parameter instead of just starting the shell, some of these tools have already been referred to. The problem with these tools is that you have to be careful to NOT record user passwords...).
The lastcomm command not showing full command.
