Linux file system permissions are more straightforward and less complex than their Windows counterparts. There are several file types:
- - = Regular File
- d = Directory (folder)
- l = Symbolic Link
- b = Block Special Device
- c = Character Device
- s = Unix Socket
- p = Named Pipe
You can view permissions by entering ls -l. Each file will have only three types of entities that can access it:
- User (u)—the file's owner
- Group (g)—any user in the file's group
- Other (o)—everybody else
Each entity can have three permissions, any of which can also be set to none (-):
- x—execute (if set on a directory, you can enter the directory and list its contents)
rwxrwxrwx = user, group, and other all have full permissions
rwxr-xr-- = user has full permissions, group can read and execute, everyone else can only read
Permissions can also be expressed in their octal equivalent. Each entity (u, g, o) has its three permissions added up into a single number:
- r = 4
- w = 2
- x = 1
- - = 0
Here are some examples. Both are regular files, as indicated by their first character, which is a "-".
-rwxrwxrwx = 777—The User has r,w,x, which is the same as 4+2+1=7. Group and Other also have the same permissions.
-rwxr-xr-- = 754—The User has r,w,x, which add up to 7, but Group only has r,x, which add up to 5, and Other only has r, which is 4.
The following example has these settings:
- It's a directory named Desktop.
- User can read, write, and execute (enter the directory to list its contents).
- Group can read and execute, but not modify.
- Other can read and execute, but not modify.
- It's owned by root, and anyone in the root group has the Group level permissions (rx), though the root user itself has full permissions (rwx).
- Another way of writing the permissions is 755.
You can assign permissions with the chmod command. For example:
- chmod 777 myfile = everyone can read, write, and execute myfile.
- chmod 644 myfile = user rw, group r, other r.
- chmod 740 myfile = user rwx, group r, others can't do anything.
Special Permission Bits
Linux also has special permission bits that are of interest to the attacker:
- setuid (SUID)—set user ID upon execution
- setgid (SGID)—set group ID upon execution
- sticky—only root or the file's owner can change files in the directory
When a file executes, it takes on the permissions of the user who launched it, not the owner who created it. This means a process can only read/write/execute what the user has permissions for. If you want to temporarily grant other users the same permissions as the owner, you can enable the SUID bit on that file. This lets the process run as owner, rather than as the user who just launched the process. As an example, say you created a script that has these permissions:
At the moment, only you (the owner) can execute it. Everyone else (including the group) can read it, but they can't run it. You want help desk technicians to also be able to run this script. You can either let them log in/sudo as you (bad idea; you don't want them to know your password) or you can change the group permissions and put them in the group (might cause problems with other files), or you can enable the SUID bit so that when they launch that one script it runs in your privilege level and actually executes. You configure SUID by replacing the owner's x with s. So the permissions would now look like this:
You can set the SUID bit on a file with this command: chmod u+s myfile. You can remove it with chmod u-s myfile.
Enabling SUID on executables runs the risk of allowing an attacker to also run that executable as its owner (which might be root!). To find programs with the SUID bit set, enter sudo find / -perm -4000.
Note: SUID uses a lowercase s, unless the file did not have execute permissions to begin with, then it uses an uppercase S. In both cases, execute is implied.
Note: Do not confuse setuid with Windows runas. In setuid, the user does not need to invoke the permission and does not need to provide any password. The SUID bit transparently grants execute permission. The Windows runas command is closer to the Linux su command, where the user must provide a password.
Similar to SUID, you could enable the SGID bit so a file can run in the file's group privilege level, rather than the user's primary group. For example, the file's group might be admins, but the user's group might be sales. You might not want to change someone out of the sales group, but you want them to run that one file as a member of the admins group. Setgid also has another behavior if set on a directory: all files inside the directory would take on the permissions of the group. You enable the SGID bit on the group permissions, not the user permissions:
To enable SGID, enter chmod g+s ourfile. To remove it, enter chmod g-s ourfile. To find programs with the SGID bit set, enter sudo find / -perm 2000.
Setting the sticky bit protects files in a common directory such as /tmp or /home. If you were to set drwxrwxrwx on /home, everyone can delete or rename each other's files. If you set the sticky bit, then people can only modify their own files. The root user, of course, can still modify everyone's files. The /tmp directory has the sticky bit set by default.
To set the sticky bit, execute this command: chmod +t <dir name>. This appends a "t" to the end of the permissions:
Remove the sticky bit with the command chmod -t <dir name>.