any user can modify files owned by root!!!

[Masaki Birchmier]

I adopted a linux system where any user can read/modify/remove files with permission
-rw-r--r-- root root
(but not files owned by other users). It's a huge security issue and I need help resolving this ASAP.

In /etc/group I have nothing out of the ordinary:
root:x:0:root
sys:x:3:root,bin.adm
adm:x:4:root,adm,daemon

There is nothing in /etc/sudoers that would allow this...

I've browsed at some of the pam files, comparing it with another system and didn't see anything, (but I'm not an expert in this area and could of missed something)

If anyone has any suggestions what might be causing this I would greatly appreciate it.

masaki

[Ivan Ferreira]

I'm pretty sure that users cannot modify the contents of the file listed, but they can delete because the deletion permission is dictated by the directory that contains the file. So, if the directory has write permissions for the user/group/others, then user/group/other can delete files in the directory, even when they are not owners of has no permissions on the file.

[Stuart Browne]

Read and remove, sure.

You've got global +r, so anybody can read it.

And Ivan's post covered the removal.

But I highly doubt you can 'modify' the contents of one of these files.

[Guru Dutta]

By looking @ the perms bits it seems that all have read access and only root or the file creator has write perms which implies that he is the person who can delete/remove it.

[Vibhor Kumar Agarwal]

I'll go the other way round.

Change your root password.

[Masaki Birchmier]

The symptom is that normal users take on the permissions of root user.
I assure you they can modify any file as long as root owns the file and has write permissions like /etc/passwd !

[Ivan Ferreira]

The only way that this could happen is that other users, besides root, have UID 0 in /etc/passwd (if its local authentication). Verify that no other user except root has UID 0 (3rd value).

[Rick Garland]

Check the UID values of the users.

There should only be 1 UID=0 and that is root.

Here is a script that can help. Modify as needed since original inception was in NIS environment.

[Masaki Birchmier]

Yup, I already checked for uid=0 in /etc/passwd.

One additional info is that although normal users can modify root owned files, they can not run root commands. It doesn't seem to matter what the group ownership/permissions are set to.

[Masaki Birchmier]

Only root has uid=0
There are several groupid=0,
sync, shutdown, halt, opertor. I think these are OK.

[Ivan Ferreira]

Do you know the specific commands that users use to modify the files?

Maybe, the commands, like vi, have the set user id bit enabled (SUID). You will see an "s" in the permissions:

-rwsr-xr-x 5 root root 331552 Jun 16 2004 /bin/vi

[Rick Garland]

Are the passwds secured?
Is sudo in play? How about PowerBroker?

Do the visudo command. This will display the sudoers file. Any clues?

Check the sudoers log file - if you have the sudo.conf file setup.

[Ivan Ferreira]

You can use the following command to find suid files:

find / -user root -perm -4000 -ls

[Masaki Birchmier]

Thanks for your input, here are the results.

Checked SUID on vi, not there.

some examples of what non root users can do
$ cd /root
permission=750 root root /root

$ cat /etc/shadow
permission=600 root root /etc/shadow

$ vi /etc/passwd
permission=644 root root /etc/passwd

sudo is not involved. If I try to use it, it promps me for root password.(sudo vi /etc/passwd)

powerbroker is not installed.

[Ivan Ferreira]

Verify the acl's, use

getfacl /etc/passwd

[Ivan Ferreira]

Verify the acl's (if exists), use

getfacl /etc/passwd

Verify that you don't have installed a rootkit. Use the rpm -V command to check the integrity of the commands in the system, and if they changed.

[Ivan Ferreira]

You should download and install chkrootkit

http://www.chkrootkit.org/

[Stuart Browne]

what was the output of 'id' when running those commands earlier?

Also, what terminal were you on? the console? ssh'd in?

[Masaki Birchmier]

It's not an ACL issue, specifically checked a few items and there are no ACL's involved.

chkrootkit, interesting tool, ran it but did not detect anything.

The userid can be any number, and all root files are available to them.

I've verified that the symptom exists when connected with ssh, and telnet.

Masaki

[Florian Heigl (new acc)]

maybe check Your /etc/shadow or /etc/passwd.master.

try to enable kernel auditing (SELinux extensions) and create an audit trail of the file accesses.

[Andrew Bruce]

If you are concerned about the security of the system (as opposed to just being curious), I would suggest at this point that you back up the user data and reinstall the server.

It sounds like you have a seriously nobbled system, and, unless you want to dissect it to find out what is happening, as opposed to just fixing the problem, reinstalling would lead back to a secure, base-lined system.

After all, you did 'adopt' it in the first place. Might as well make it truly yours!

Regards,

Andy