Linux: Check those file permissions!
Linux determines who may access files and directories on the system, and in what way, by using file permissions. Permissions are defined by three groups of users, and three sets of permissions. Users are grouped into the user who owns the file, the group to which the file belongs, and everybody else. Permissions available are read, write, and execute. The permissions of a file may be viewed with the ls -l command:
ls -l /usr/share/xmms
drwxr-xr-x 17 root root 4096 08-19 11:47 Skins
-rw-r--r-- 1 root root 7972 08-17 08:11 wmxmms.xpm
The example above is the contents of /usr/share/xmms on my system. The output of this command shows just about everything that can be known about the files in this derectory. The contents of the output columns are as follows:
1-file permissions
2-number of links to the file
3-user who owns the file
4-group the file belongs to
5-size of the file
6-date and time of creation
7-name of the file
The first, third, and fourth columns are the ones that interest us. The contents of the first column, which defines the permissions of the file, will always be ten characters and can be broken down as the first character by itself, and then three groups of three. The first character specifies whether the item is a file or a directory with either a "d" or a blank. You can see in the example above that "Skins" is a directory, while "wmxmms.xpm" is a file.
The next three characters specify the "rwx" (read, write, and execute) permissions for the user who owns the file, in this case root. In the example, root has read, write, and execute permission for the "Skins" directory, read and write permission for "wmxmms.xpm," but not execute. This is because wmxmms.xpm is an icon and not a binary, so there is no need to execute it. (Note: the x bit must be set on directories in order for the user to cd into it.)
The second group of three specifies the "rwx" permissions for any user belonging to the group of the file, in this case also root. Group members have read and execute permission on "Skins" but may not write to it. They also have read permission on "wmxmms.xpm" but not write or execute. The effect is that everything is accessible to members of the group, but as read-only.
The third group of three specifies the "rwx" permissions for everyong else. In this case, they are the same as for the group: read-only.
There is one additional bit that defines a file's permissions: the SUID (or SGID) bit. In Linux, a binary executes with the same permissions as the user executing it. By setting the SUID bit on a file, it always executes with the permissions of its owner, who is usually root. This can be a useful way to allow users to perform tasks that are normally reserved for root, but it also opens a door for an attacker to escalate his privileges to root. A SUID file would look like this:
ls -l /bin/su
-rwsr-xr-x 1 root root 20448 08-16 12:48 /bin/su
You can see that the "x" bit in the owner section has been replaced by a new "s" bit, indicating that the file is SUID. The owner is root, so any user executing this file will do so with root privileges. Generally not a good idea, but sometimes necessary for binaries like su.
Knowing how to read file permissions, they may now be changed with the chmod command. Let's take a real-world example that comes up quite often - burning CDs in Linux. The cdrecord command requires root privileges in order to scan the SCSI bus and find the drive, and many new users will make the mistake of setting the SUID bit on cdrecord to get around the problem. This is *BAD* because it opens up a security hole you could drive a truck through. The proper way to do it is to create a group called "cdwriter" with the groupadd command, and then fix the file permissions of cdrecord so that only members of that group can execute it with owner privileges. Let's look at cdrecord in its unaltered state:
ls -l /usr/bin/cdrecord
-rwxr-xr-x 1 root root 257516 08:21 14:24
The file is owned by root, and the group is root. The owner has rwx permission, the group has rx permission, and everybody else has rx permission. Ownership is changed with the chown command, followed by the owner and the group separated by a period. We want the file to belong to the cdwriter group, so we execute the chown command like so:
chown root.cdwriter /usr/bin/cdrecord
A look at the output of ls should now show this:
ls -l /usr/bin/cdrecord
-rwxr-xr-x 1 root cdwriter 257516 08:21 14:24
Now we want to set the permissions so that users who are not members of the cdwriter group cannot execute the file. Permissions are modified with the chmod command, followed by the group of users you want to affect and a plus or minus permission. The format for users is u (user, or owner) g (group) or o (other), a + or - to indicate whether the permission is being added or removed, and then the appropriate rwx permission. It looks like chmod (ugo) (+-) (rwx). So to remove the x permission from others, we would execute the chmod command like so:
chmod o-x /usr/bin/cdrecord
Once again, looking at the output of ls, we see the following:
ls -l /usr/bin/cdrecord
-rwxr-xr-- 1 root cdwriter 257516 08-21 14:24 /usr/bin/cdrecord
Now, owner root has rwx permission, members of the group have rx permission, and everybody else can see the file and not execute it. Users who are members of the cdwriter group will now be able to execute this file with owner privileges, and everyone else will be left out in the cold.
File permissions are an integral part of working with Linux, and it's impossible to have a secure system without understanding them. For information on permissions, see man chown and man chmod from a command line.
