Security Handbook/File permissions

This section is on securing system files. == File permissions ==

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.

World/Group writable
Find world-writable files and directories:

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 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 on them or unmerge the package that they came from (check which package they belong to by using ; if you do not already have it installed simply type ). Otherwise just turn the SUID bit off with.

Find setuid files:

This will create a file containing a list of all the SUID/SGID files.

List of setuid binaries:

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 {{c|ping, {{c|mount, {{c|umount}}, {{c|chfn}}, {{c|chsh}}, {{c|newgrp}}, {{c|suidperl}}, {{c|pt_chown}} and {{c|traceroute}} by executing on every file. Don't remove the bit on {{c|su}}, {{c|qmail-queue}} or {{c|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 {{c|su}}, {{c|passwd}}, {{c|gpasswd}}, {{c|qmail-queue}}, {{c|unix_chkpwd}} and {{c|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 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  or   (for example, if, , or  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 command.

To find the SUID and SGID files with multiple links, use :