File permissions, the most basic form of security control that exists on Unix-like systems, is still misunderstood by many.
Linux has many different level of security. The kernel is protected from user processes; a user can only affect his own processes; and user processes are protected from each other. This security model requires that you must specifically allow users and processes to interact, otherwise there is no avenue for interaction and thus no avenue for attack.
The most basic security feature of any unix-like operating system is file permissions. However, even though this is the most simple line of defence, it is still misunderstood by many. Frequently, in an administrator perspective, I need to re-teach users how file perms work when they find that other users can access files they thought were unaccessible. Worse yet is when poor file permissions are used as part of an attack that should never have had a chance.
File permissions are those letters you see at the beginning of ls -loutput:
$ ls -l drwxrwxrwx 1 reegen reegen 4096 Jan 22 10:05 dropbox drwx------ 1 reegen reegen 4096 Dec 6 8:50 private_logs -rw-r--r-- 1 reegen reegen 9663 Oct 8 16:03 public -rw------- 1 reegen reegen 8925 Jan 12 11:17 secret
The first part of the output has 10 characters, which can be broken up as follows (excuse the ASCII art….)
d rwx rwx rwx | | | | | | | -> "Other" permissions | | | | | -> "Group" permissions | | | -> "User" permissions | -> Type of file
The first character says what kind of file this is. (d==directory, l==symlink, p==pipe, s==socket, etc). The next three groups define the permissions of this file. An “r” means “allow read access”, a “w” means “allow write access”, and “x” means “allow execute access.
The kernel decides if you have read/write/execute access based on these rwxbits. Say you want to read a file — what logic does the kernel use to decide if you should be granted read access? Test your intuition with the following examples:
$ id uid=1000(doug) gid=1000(doug) groups=1000(doug),1001(web)
$ ls -l foo.html -rw-r----- 1 www-data web 9663 Oct 8 16:03 foo.html
Following this logic, we’d all agree that doug can read this file, because he’s part of the group web, which has read access. However how about this situation:
$ id uid=1000(doug) gid=1000(doug) groups=1000(doug),1001(web)
$ ls -l bar.html -rw----r-- 1 www-data web 19838 Sep 17 4:22 bar.html
Most people’s intuition would say sure, doug can read this file, since the read bit is set for other. This is not the case!
Standard file permissions come in three flavours: user, group, and other. Many people think that if any option is satisfied, then access is granted. In reality, the kernel checks only the most appropriate – it does not “check all of them, falling through when a particular test fails”!
So, to be explicit, here is how you can think of the file permission logic, using read access as an example:
- If the user is the owner of the file, see if the owner read bit (400) is set. If not, tough luck. Do no other tests.
- If the user is a member of the group that owns the file see if the group read bit (040) is set. If not, tough luck. Do no other tests.
- If the user is not the owner of the file nor a member of the group that owns the file, see if the other read bit (004) is set. If not, tough luck. Do no other tests.
The distinction is an important one. You could create a file that you own that is readable by group and other, but not by you[3]. Yes, this seems somewhat counterintuitive.
We are frequently put in a position where we want to give only certain users access to a directory or files. We put them in a special group, and tailor the group permissions of the files/directories to allow them this special access. Say we wanted to have the compiler only available to developers, we may do the following:
# ls -l /usr/bin/gcc -rwxr-xr-x 1 root root 74088 Sep 23 15:13 /usr/bin/gcc
# addgroup devel # chgrp devel /usr/bin/gcc # ls -l /usr/bin/gcc -rwxr-xr-x 1 root devel 74088 Sep 23 15:13 /usr/bin/gcc
# chmod o-rx /usr/bin/gcc # ls -l /usr/bin/gcc -rwxr-x--- 1 root devel 74088 Sep 23 15:13 /usr/bin/gcc
Now only root and the users in the devel group can run gcc. This is the kind of group modifications we most frequently make. But what happens if we want to have almost everyone able to use gcc except for a few troublemakers? We can add everyone to this group, but that’s a management pain. But remember – the kernel only checks the best match from user/group/other, not all of them. So instead, we do things the other way around:
# ls -l /usr/bin/gcc -rwxr-xr-x 1 root root 74088 Sep 23 15:13 /usr/bin/gcc # addgroup jerks # chgrp jerks /usr/bin/gcc # ls -l /usr/bin/gcc -rwxr-xr-x 1 root jerks 74088 Sep 23 15:13 /usr/bin/gcc # chmod g-rx /usr/bin/gcc # ls -l /usr/bin/gcc -rwx---r-x 1 root jerks 74088 Sep 23 15:13 /usr/bin/gcc
What do we have now? gcc can only be run by root, and anyone not in the group jerks. We can maintain the (hopefully short) list of jerks much more easily than adding everyone to the devel group. The management nightmare is over.
NOTES:
[1] Of course, if the file isn’t an executable program, shell script, or other recognisable form, Linux will stick its tongue out at you.
[2] Even compiled executables can often be run without the execute bit, such as using /lib/ld-linux.so.2 program_name. You loose the ability to run setuid/setgid programs with their extra permissions if you use any of these methods.
[3] Of course you could always chmod it since you own it.
Hacking Linux Exposed– covers the myriad ways a malicious hacker will attack your Linux system, and the rationale behind such behavior. While the bad guys are well versed in such techniques, this book serves to educate the home user as well as the overworked and underpaid system administrator who is not only responsible for the operation of mission-critical Linux servers, but who must vigilantly secure them on a daily basis. 
Brian Hatch is Chief Hacker at Onsight, Inc and author of
Hacking Linux Exposed
and Building Linux VPNs.
Brian can be reached at brian@hackinglinuxexposed.com.
