sudoers problem

[khilari]

Hi guys, actually what happened is that recently a user who was in the /etc/sudoers file with root permissions tried to su to root and was told that his userid is not in the sudoers file... Now, no body made any changes and this user has been using the sudoers for quite a while now.. I readded his name and he could use the sudo access again.
But as part as my investigation as to what happened where should i begin.. In the syslog.log file it only tells the time the user tried to log in and got the error message.
Thanks

[Patrick Wallek]

It's a bit late now.

Double-checking the sudoers file and verifying that his user id was there and set up correctly would have been my first step.

If you have a backup copy of the file from the time this occurred you could still investigate.

Otherwise, there is not much to look at now.

[Mel Burslan]

If you can share the sudoers line where he is being authorized to have root level access, that would help brainstorming.

Shooting from the hip, I can think of one way this could have happened: this user's root level access was covered by a group membership in sudoers file such as:

%sysadm ALL = (ALL) ALL

and he was a sysadm member in /etc/groups file (or his/her primary group was set as sysadm. Somebody changing this might have caused the user lose access to root level.

HTH

[Bill Hassell]

Check the timestamp on your sudoers file. When was it last changed? Only root can do this so backtrack through root's shell history looking for visudo or any reference to sudoers. Look for root hacks like sudo sh in the sudo log file. Using sudo to run a shell, while convenient, should be a violation of corporate policy. Check also any restores from backup media. And of course, using the ubiquitous (but not secure at all) construct: ALL = (ALL) ALL means that the user or group of users with that designation have keys to the kingdom -- a bad thing in security and proper privilege separation.