[SOLVED] many users has root password and how to find who did what
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
many users has root password and how to find who did what
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.
Quote:
May I ask why your users have to have the root password?
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.
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.
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.
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.
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.
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?.
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.
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.
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.
No ,it will save the log like like this.
in /var/log it will save with root_history-username-AndDateFormat
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.
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.
@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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.