World readable
Normal users should not have access to configuration files or passwords. An attacker can steal passwords from databases or web sites and use them to deface--or even worse, delete--data. This is why it is important that your file permissions are correct. If you are sure that a file is only used by root, assign it with the permissions 0600 and assign the file to the correct user with chown.
Finding world-writable files and directories |
# find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \; 2>/dev/null >writable.txt |
This will create a huge file with permission of all files having either write
permission set to the group or everybody. Check the permissions and eliminate
world writable files to everyone, by executing /bin/chmod o-w on the
files.
SUID/SGID files
Files with the SUID or SGID bit set execute with privileges of the owning
user or group and not the user executing the file. Normally these bits are used
on files that must run as root in order to do what they do. These files can lead
to local root compromises (if they contain security holes). This is dangerous
and files with the SUID or SGID bits set should be avoided at any cost. If you
do not use these files, use chmod 0 on them or unmerge the package that
they came from (check which package they belong to by using equery; if
you do not already have it installed simply type emerge
gentoolkit). Otherwise just turn the SUID bit off with chmod -s.
Finding setuid files |
# find / -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \; 2>/dev/null >suidfiles.txt |
This will create a file containing a list of all the SUID/SGID files.
List of setuid binaries |
/bin/su |
By default Gentoo Linux does not have a lot of SUID files (though this depends
on what you installed), but you might get a list like the one above. Most of
the commands should not be used by normal users, only root. Switch off the SUID
bit on ping, mount, umount, chfn, chsh,
newgrp, suidperl, pt_chown and traceroute by
executing chmod -s on every file. Don't remove the bit on su,
qmail-queue or unix_chkpwd. Removing setuid from those files will
prevent you from su'ing and receiving mail. By removing the bit (where
it is safe to do so) you remove the possibility of a normal user (or an
attacker) gaining root access through any of these files.
The only SUID files that I have on my system are su, passwd,
gpasswd, qmail-queue, unix_chkpwd and pwdb_chkpwd.
But if you are running X, you might have some more, since X needs the elevated
access afforded by SUID.
SUID/SGID binaries and Hard links
A file is only considered deleted when there are no more links pointing to it.
This might sound like a strange concept, but consider that a filename like
/usr/bin/perl is actually a link to the inode where the data is
stored. Any number of links can point to the file, and until all of them are
gone, the file still exists.
If your users have access to a partition that isn't mounted with nosuid
or noexec (for example, if /tmp, /home, or
/var/tmp are not separate partitions) you should take care to
ensure your users don't create hard links to SUID or SGID binaries, so that
after Portage updates they still have access to the old versions.
To check how many links a file has, you can use the stat command.
Stat command |
$ stat /bin/su |
To find the SUID and SGID files with multiple links, you can use find.
Finding multiply linked suid/sgid binaries |
$ find / -type f \( -perm -004000 -o -perm -002000 \) -links +1 -ls |
Powered by ScribeFire.
