Many users has root password on Debian Linux server. Some body has changed some permission on some directories. I need to find which user did this. Is there any way to find specifically who did this?.

No, you can't since all users have logged in as the same user. You should consider to use a sudo setup with fine grained restrictions and logging possibilities instead.
May I ask why your users have to have the root password?

I forget to mention one thing. Every user has their own account setup with ssh key based login. So every user login by thier own account and then they su to root.
It is kind of legacy thing. Even I don't know. I am new there and let's see how much it will take me to convince my seniors, that this is not the right way. . I am trying to setup the environment, so that developers/non-admin users can do their task without root access.

It doesn't make a difference if the users first login as their own users and than su to root, at that point they are root and not differentiable.
Sometimes legacy setups can be quite inconvenient and even dangerous. Good luck with convincing your seniors to implement a clean and secure solution.

yes it is possible by saving their logs.
In debian you have to do some settings.

* Allow users to do "sudo su - " only .So that they become root.
* I implemented this method and keeping track of users successfully . I have written same in my blog.Read the post and with debian system do some changes. I did this in CentOS/Red Hat. And the same logic you can use with Debian also.Here you have play with .bash_profile of users.

http://sharadchhetri.com/2011/12/02/...ndary-logging/

It is not possible in the OP's case, without using sudo, but only su. I would also rather recommend to setup sudo in the way it is intended, giving the users only the rights they absolutely need for their job. This is common practice and known as Principle of least privilege.

1 members found this post helpful.

Yes, but not the way you do it.


Only because you don't have (or don't audit for?) malicious users. Basically what you do amounts to:
It uses the shells internal relative time stamping, uses 'whoami' incorrectly (will always return "root" when used there) but most importantly can all be reverted or fscked up once somebody is root.

The problem (apart from your obvious problem that is) is Linux doesn't come with an all-encompassing audit trail out of the box. On a machine that doesn't use remote syslog in combination with the audit service and Rootsh or any other logging shell what remains is:
- user login records in /var/log/wtmp ('man last'),
- if you touched /var/log/btmp you also have bad logins there ('man lastb'),
- PAM user login records in /var/log/secure or equivalent,
- if BSD Process Accounting was enabled (psacct) the 'sa', 'lastcomm' and related commands,
- possibly login records in networked service daemon logs,
- users shell history, and
- file system MAC time stamps.

Correlation, creating a time line out of log file entries, login records, user shell history, 'lastcomm --user [someaccountname]' and file system MAC time stamps may to some extent reveal when and in what order the system was altered but it will always be an incomplete picture and you won't be able to assert whatever you (think you) see is free of tampering.

(When pondering a better audit trail see http://www.linuxquestions.org/questi...8/#post3997650 and http://www.linuxquestions.org/questi...patches-34823/.)

1 members found this post helpful.

will always return "root" when used there
No ,it will save the log like like this.
in /var/log it will save with root_history-username-AndDateFormat
Kindly try in your system first. I tried in CentOS and it is in production environment.

I am not misleading anyone with this information. Some blogs has already shared this link. All the things which I have written in my blog are practically done.

First do the try and let me know.

Yes, you're right, it does. But regardless of that logging this way isn't tamper-free as root can alter any variables and files and it only logs commands executed on the command line whereas Rootsh can log even what you type inside a CLI text editor. So this still can't or shouldn't be part of what I'd define as a proper audit trail.

Ok I got it, when a user become root he can do anything.But user will think before if he do anything mischievous.
(1)We can save the log in remote server as well.
(2)second thing we should use chattr command to immute the log dir as well as .bashrc.So that if anyone will try to remove immute on directory, we can capture his activity in local and remote log server also.
(3)here the last login in server log must also be remotely saved.
(4)We must have a single centralised server (bation host) only from which user can do login. In that server user only restricted to use ssh to other server.In this server also, we can use this logging system .
Through last 3 and 4 step we can track who was last person who tried to login in that server.
(5) Co. must have policy,user should not share their credential to anyone.If they do Co. should take proper action on him/her.

I hope by this way we can achieve almost main concern of Question that is user should not do any damage in server. So user will think before what he is doing.

1 members found this post helpful.

and it is better to have something rather then nothing.

@schneidz , appreciate you also pointed out good thing .

I would like to share my personal experience when auditor asked why the recommended settings are not in place.The file was edited before 6 month
At that time I found the guy who did the changes. timestamp of files and directory also matters if they exist.If someone remove log is there

As unSpawn said about rootsh. That is also good thing. http://linux.die.net/man/1/rootsh .We can utilise both things together.