unauthorised file erase

pingvina · 02-20-2006, 03:23 PM

how's that possible??
i have files in /home/user dir owned by root
and i can erase them when i'm not logged in as root!!
help!!!!

Sargek · 02-20-2006, 03:30 PM

Your user is not part of the root group, is it?

pingvina · 02-20-2006, 03:41 PM

/etc/group:
root:x:0:root
user:x:1001:
hmm why user group finishes with : ??

jschiwal · 02-20-2006, 03:51 PM

The colon at the end is correct. Make sure that you don't have the user or users group as the default group for root. Make sure that the the /root directory and files have root ownership and root group ownership and that the "o" permission bits are cleared.
Make sure that the UMASK variable for root masks out the other bit on newly created files.
Also check the group membership of each of the members. The line you have shown shows who are members of the "user" group.

pingvina · 02-20-2006, 03:59 PM

what is "o" permission bits??
UMASK - /etc/profile:
default - 022
should i make different UMASK for root?

less /etc/group | grep root:

root:x:0:root
bin:x:1:root,bin,daemon
daemon:x:2:root,bin,daemon
sys:x:3:root,bin,adm
adm:x:4:root,adm,daemon
tty:x:5:root
disk:x:6:root,adm
wheel:x:10:root
floppy:x:11:root,user

tnx

pingvina · 02-20-2006, 04:40 PM

i changed root's umask to 077
created new file with perms -rw-------
and succesfully deleted it when not logged as root!!

jschiwal · 02-20-2006, 05:17 PM

Check that this user doesn't have a uid of 0.

Check the permissions of the commands in /bin and /usr/bin. See if some of them are SUID root. If so, when they run, they run as the owner of the file, which would be root. Only a small handful of programs should have the SUID bit set. Also make sure the GUID bit isn't set on the /bin and /sbin and /usr/bin and /usr/sbin directories. That would have the same effect, giving group membership to any user running such a command.

If you find that a large number of programs have the suid bit set, you better figure out how and when it happened. If your system has been on the net, and someone was able to crash a service they may of been given root access by simply running /bin/bash, if bash is also suid root. You may consider re-installing, because with these permissions problems, you can't trust any program anymore, and starting from scratch would be the safest thing to do.

There is a distro that is sold in stores (LINSPIRE) that gives every user root access. This is so people accustomed to running Windows 98 don't get put off by having to enter the root password to install programs.

I don't know whether Gentoo uses PAM and the shadow suite. You may also want to examine the /etc/gshadow file. The third field lists admin members, which may cause a problem.

You may try an experiment. Create a new user, and log in as that user. Don't make this user a member of any special group. See if this new user also has root powers.

pingvina · 02-20-2006, 06:02 PM

/bin
"ls -l | grep rws"
-rwsr-xr-x 1 root bin 61308 2005-01-02 04:56 mount
-rws--x--x 1 root bin 29232 2004-11-04 06:55 ping
-rws--x--x 1 root bin 26800 2004-11-04 06:55 ping6
-rws--x--x 1 root bin 35780 2004-06-21 22:20 su
-rwsr-xr-x 1 root bin 32180 2005-01-02 04:56 umount

/usr/bin
"ls -l | grep rws"
-rws--x--x 1 root bin 34540 2004-06-21 22:20 chage
-rws--x--x 1 root bin 29492 2004-06-21 22:20 chfn
-rws--x--x 1 root bin 27780 2004-06-21 22:20 chsh
-rws--x--x 1 root bin 10508 2002-04-16 05:09 crontab
-rws--x--x 1 root bin 16652 2004-06-21 22:20 expiry
-rwsr-x--- 1 root smmsp 19076 2002-05-01 05:23 fdmount
-rws--x--x 1 root bin 34616 2004-06-21 22:20 gpasswd
-rws--x--x 1 root bin 19948 2004-06-21 22:20 newgrp
-rws--x--x 1 root bin 37880 2004-06-21 22:20 passwd
-rwsr-sr-x 1 root mem 66240 2002-06-05 21:11 procmail
-rws--x--x 1 root bin 93056 2005-01-26 05:23 sudo
-rws--x--x 1 root bin 16100 2003-03-03 04:28 traceroute
-rws--x--x 1 root bin 10148 2004-11-04 06:55 traceroute6

no such files in /sbin and /usr/sbin

/usr
drwxr-xr-x 2 root bin 24576 2006-02-11 19:46 bin
drwxr-xr-x 2 root daemon 4096 2006-02-11 19:47 sbin

/
drwxr-xr-x 2 root root 4096 2004-12-26 14:42 bin
drwxr-xr-x 2 root root 8192 2006-01-14 19:07 sbin

stress_junkie · 02-20-2006, 06:26 PM

I have the same thing.

Here I log on as root and change to the tmp directory under /home/melvin, which is the home directory of user melvin.

Code:

# whoami
root

# pwd
/home/melvin/tmp

# echo delete me > delete.tmp

# ls -l delete.tmp
-rw-------  1 root root 10 Feb 20 19:21 delete.tmp
#

Now I log on as melvin and change to the same tmp directory. Then I delete the file that was created by root with 600 file protection.

Code:

$ whoami
melvin

$ groups
users melvin

$ cd
$ cd tmp
$ ls -l
total 1
-rw-------  1 root root 10 2006-02-20 19:17 delete.tmp

$ rm delete.tmp
rm: remove write-protected regular file `delete.tmp'? y
removed `delete.tmp'

$ ls -l
total 0

$ alias rm
alias rm='rm -v'

$ /usr/bin/which --skip-alias rm
/bin/rm

$ ls -l /bin/rm
-rwxr-xr-x  1 root root 38573 2005-04-20 10:32 /bin/rm
$

???

pingvina · 02-20-2006, 06:50 PM

created new user... still capable of deleting root files in /home/"user" directory..
i tried in /root.. it;s not happening there....

dive · 02-20-2006, 06:56 PM

does your sudoers file show anything wrong? (visudo as root)

jschiwal · 02-20-2006, 06:58 PM

As the regular user, type in the groups command to see which groups you are a member of.

If you are a member of the wheel group, then what you see may be normal. I'm not sure about the "disk" group.

Create a new normal user. Lets say that this new user is a member of the groups: users dialout audio cdrom video
I bet that the test you just performed will not succeed this time. This would be good news in that you don't have a permissions problem for ordinary users.

gilead · 02-20-2006, 07:57 PM

The ability to delete a file relates to the privileges of the directory the file is in. If you have write privileges on the directory you can delete files in it.

To stop this happening, set the directory's sticky bit with chmod -c 1777 directoryname. Have a look at ls -ld /tmp, you should see something like:

Code:

$ ls -ld /tmp
drwxrwxrwt  18 root root 4096 2006-02-21 11:48 /tmp

Then try (use files from your own system, of course):

Code:

$ ls -l /tmp/swapinfo.txt
-rw-r-----  1 oracle oinstall 99 2006-02-21 11:35 /tmp/swapinfo.txt
$ rm /tmp/swapinfo.txt
rm: remove write-protected regular file `/tmp/swapinfo.txt'? y
rm: cannot remove `/tmp/swapinfo.txt': Operation not permitted

jschiwal · 02-20-2006, 08:35 PM

Yes, gilead, you are correct. It is because the user has write permissions in that directory, and has nothing to do with being a member of the wheel group. ( Where was my brain? )

Pingvina, when you delete a file, you are not writing to the file, but writing a change to the directory. In your home directory you have write access so you can do that. To the kernel, the directory is actually a file, and it is the permissions of that (directory) file that is checked. The /tmp directory is the one directory that is globally writable and so the sticky bit is set for it.

If you own the directory, you will still be able to remove a root owned file in the directory, even with the sticky bit set, according to the coreutils info page:

Quote:

3. save the program's text image on the swap device so it will load
more quickly when run (called the "sticky bit"). For directories
on some systems, prevent users from removing or renaming a file in
a directory unless they own the file or the directory; this is
called the "restricted deletion flag" for the directory.

pingvina · 02-21-2006, 07:11 AM

so root is not allmighty??