Your question is rather broad, touching on several different subjects. It may be better to take some of the details and put them in a separate question.
Is it enough to forbid
su and allow
sudo in order to keep the traceability of the administrator actions?
... can sudo command have utility without a strong sudoer configuration ? which ones ?
sudo has a couple benefits over
sudoer can use his personal password. This way you do not have to re-distribute the root password if it is changed.
sudo can be configured to log activity. If your
syslog configuration writes to a remote location, then it becomes difficult for someone to cover their tracks.
root access is still 'unrestricted'.
If you do not use a remote
syslog server then tracks can easily be covered.
For convenience, folks often will use
sudo -s to get an interactive shell. This allows you to get
bash autocomplete on restricted directories. Unfortunately, the
syslog benefits are void if a person is allowed to run
sudo -s. Also there are many alternatives to
sudo -s that can allow commands to be run without specific logging.
(I can imagine a scenario where a user does a lot of sudo actions before deleting his bash_history)
bash_history is not to be used as a history trace tool. It is only for user convenience.
Is there another source beside .bash_history useful to keep traceability? can such a file be updated by an administrator (with sudo)?
Any files on the server can be updated by a person with unrestricted
root access. (whether via
How to trace the activity of a
root user may be the subject of a different question. I believe advanced configurations of SELinux can do this, but it is probably not practical. I don't know of any other way to trace activity of a
As I said if you have any logging that will have to be written to a remote log server to keep those from being erased by the attacker.
is it possible to restrict sudo -i and sudo -s in the configuration ?
To answer you verbatim, this may be possible, but is beyond the scope of this post. Consider creating a new question.
However, this will not solve your problem. For example, one could use
sudo su instead of
sudo -s. One could use
sudo sudoers, or update the
The only way to solve this is to 'restrict' the
sudo abilities using a whitelist. As you said, this is not nearly as common, but is certainly the only way to accomplish the goal of reliable traceability with any level of detail.
Hope this helps. Feel free to ask for clarification on my answer, or post a more specific question if you have new questions based on what you learned so far.