Not every user of a single operating system should have the same level of access to files and directories. Like any professional or enterprise-level operating system, Linux has methods for securing file and directory access. This security system allows the system administrator—the root user—or the file owner to protect their files from unwanted access or tampering by granting select users permissions to read, write, or execute files. For each file and directory, we can specify the permission status for the file’s owner, for particular groups of users, and for all other users. This is a necessity in a multiuser, enterprise-level operating system. The alternative would be quite chaotic.
In this chapter, I’ll show you how to check for and change permissions on files and directories for select users, how to set default file and directory permissions, and how to set special permissions. Finally, you will see how a hacker’s understanding of permissions might help them exploit a system.
As you know, in Linux, the root user is all-powerful. The root user can do basically anything on the system. Other users on the system have more limited capabilities and permissions and almost never have the access that the root user has.
These other users are usually collected into groups that generally share a similar function. In a commercial entity, these groups might be finance, engineering, sales, and so on. In an IT environment, these groups might include developers, network administrators, and database administrators. The idea is to put people with similar needs into a group that is granted relevant permissions; then each member of the group inherits the group permissions. This is primarily for the ease of administering permissions and, thus, security.
The root user is part of the root group by default. Each new user on the system must be added to a group in order to inherit the permissions of that group.
Each and every file and directory must be allocated a particular level of permission for the different identities using it. The three levels of permission are as follows:
r Permission to read. This grants permission only to open and view a file.
w Permission to write. This allows users to view and edit a file.
x Permission to execute. This allows users to execute a file (but not necessarily view or edit it).
In this way, the root user can grant users a level of permission depending on what they need the files for. When a file is created, typically the user who created it is the owner of the file, and the owning group is the user’s current group. The owner of the file can grant various access privileges to it. Let’s look at how to change permissions to pass ownership to individual users and to groups.
To move ownership of a file to a different user so that they have the ability to control permissions, we can use the chown (or change owner) command:
kali >chown ➊bob ➋/tmp/bobsfile
Here, we give the command, the name of the user we are giving ownership to, and then the location and name of the relevant file. This command grants the user account for Bob ➊ ownership of bobsfile ➋.
To transfer ownership of a file from one group to another, we can use the chgrp (or change group) command.
Hackers are often more likely to work alone than in groups, but it’s not unheard of for several hackers or pentesters work together on a project, and in that case, using groups is necessary. For instance, you might have a group of pentesters and a group of security team members working on the same project. The pentesters in this example are the root group, meaning they have all permissions and access. The root group needs access to the hacking tools, whereas the security folk only need access to defensive tools such as an intrusion detection system (IDS). Let’s say the root group downloads and installs a program named newIDS; the root group will need to change the ownership to the security group so the security group can use it at will. To do so, the root group would simply enter the following command:
kali >chgrp ➊security ➋newIDS
This command passes the security group ➊ ownership of newIDS ➋.
Now you need to know how to check whether these allocations have worked. You’ll do that by checking a file’s permissions.
When you want to find out what permissions are granted to what users for a file or directory, use the ls command with the –l (long) switch to display the contents of a directory in long format—this list will contain the permissions. In Listing 5-1, I use the ls –l command on the file /usr/share/hashcat (one of my favorite password-cracking tools) in order to see what we can learn about the files there.
kali >ls –l /usr/share/hashcat
total 32952
➊ ➋ ➌ ➍ ➎ ➏ ➐
drwxr-xr-x 5 root root 4096 Dec 5 10:47 charsets
-rw-r--r-- 1 root root 33685504 June 28 2018 hashcat.hcstat
-rw-r--r-- 1 root root 33685504 June 28 2018 hashcat.hctune
drwxr -xr-x 2 root root 4096 Dec 5 10:47 masks
drwxr -xr-x 2 root root 4096 Dec 5 10:47 OpenCL
drwxr -xr-x 3 root root 4096 Dec 5 10:47 rules
Listing 5-1: Checking a file’s permissions with the long listing command
On each line, we get information about:
➊ The file type
➋ The permissions on the file for owner, groups, and users, respectively
➌ The number of links (This topic is beyond the scope of the book.)
➍ The owner of the file
➎ The size of the file in bytes
➏ When the file was created or last modified
➐ The name of the file
For now, let’s focus on the seemingly incomprehensible strings of letters and dashes on the left edge of each line. They tell us whether an item is a file or directory and what permissions, if any, are on it.
The first character tells you the file type, where d stands for a directory and a dash (–) indicates a file. These are the two most common file types.
The next section defines the permissions on the file. There are three sets of three characters, made of some combination of read (r), write (w), and execute (x), in that order. The first set represents the permissions of the owner; the second, those of the group; and the last, those of all other users.
Regardless of which set of three letters you’re looking at, if you see an r first, that user or group of users has permission to open and read that file or directory. A w as the middle letter means they can write to (modify) the file or directory, and an x at the end means they can execute (or run) the file or directory. If any r, w, or x is replaced with a dash (-), then the respective permission hasn’t been given. Note that users can have permission to execute only either binaries or scripts.
Let’s use the third line of output in Listing 5-1 as an example:
-rw-r--r-- 1 root root 33685504 June 28 2018 hashcat.hcstat
The file is called, as we know from the right end of the line, hashcat.hcstat. After the initial – (which indicates it’s a file), the permissions rw- tell us that the owner has read and write permissions but not execute permission.
The next set of permissions (r--) represents those of the group and shows that the group has read permission but not write or execute permissions. And, finally, we see that the rest of the users also have only read permission (r--).
These permissions aren’t set in stone. As a root user or file owner, you can change them. Next, we’ll do just that.
We can use the Linux command chmod (or change mode) to change the permissions. Only a root user or the file’s owner can change permissions.
In this section, we use chmod to change permissions on hashcat.hcstat using two different methods. First we use a numerical representation of permissions, and then we use a symbolic representation.
We can use a shortcut to refer to permissions by using a single number to represent one rwx set of permissions. Like everything underlying the operating system, permissions are represented in binary, so ON and OFF switches are represented by 1 and 0, respectively. You can think of the rwx permissions as three ON/OFF switches, so when all permissions are granted, this equates to 111 in binary.
A binary set like this is then easily represented as one digit by converting it into octal, an eight-digit number system that starts with 0 and ends with 7. An octal digit represents a set of three binary digits, meaning we can represent an entire rwx set with one digit. Table 5-1 contains all possible permission combinations and their octal and binary representatives.
Table 5-1: Octal and Binary Representations of Permissions
Binary |
Octal |
rwx |
000 |
0 |
--- |
001 |
1 |
--x |
010 |
2 |
-w- |
011 |
3 |
-wx |
100 |
4 |
r-- |
101 |
5 |
r-x |
110 |
6 |
rw- |
111 |
7 |
rwx |
Using this information, let’s go through some examples. First, if we want to set only the read permission, we could consult Table 5-1 and locate the value for read:
r w x
4 - -
Next, if we want to set the permission to wx, we could use the same methodology and look for what sets the w and what sets the x:
r w x
- 2 1
Notice in Table 5-1 that the octal representation for -wx is 3, which not so coincidently happens to be the same value we get when we add the two values for setting w and x individually: 2 + 1 = 3.
Finally, when all three permissions are on, it looks like this:
r w x
4 2 1
And 4 + 2 + 1 = 7. Here, we see that in Linux, when all the permission switches are on, they are represented by the octal equivalent of 7.
So, if we wanted to represent all permissions for the owner, group, and all users, we could write it as follows:
7 7 7
Here’s where the shortcut comes in. By passing chmod three octal digits (one for each rwx set), followed by a filename, we can change permissions on that file for each type of user. Enter the following into your command line:
kali >chmod 774 hashcat.hcstat
Looking at Table 5-1, we can see that this statement gives the owner all permissions, the group all permissions, and everyone else (other) only the read permission.
Now we can see whether those permissions have changed by running ls -l on the directory and looking at the hashcat.hcstat line. Navigate to the directory and run that command now:
kali >ls -l
total 32952
drwxr-xr-x 5 root root 4096 Dec 5 10:47 charsets
➊ -rwxrwxr-- 1 root root 33685504 June 28 2018 hashcat.hcstat
-rw-r--r-- 1 root root 33685504 June 28 2018 hashcat.hctune
drwxr -xr-x 2 root root 4096 Dec 5 10:47 masks
drwxr -xr-x 2 root root 4096 Dec 5 10:47 OpenCL
drwxr -xr-x 3 root root 4096 Dec 5 10:47 rules
You should see -rwxrwxr-- on the left side of the hashcat.hcstat line ➊. This confirms that the chmod call successfully changed permissions on the file to give both the owner and the group the ability to execute the file.
Although the numeric method is probably the most common method for changing permissions in Linux, some people find chmod’s symbolic method more intuitive—both methods work equally well, so just find the one that suits you. The symbolic method is often referred to as the UGO syntax, which stands for user (or owner), group, and others.
UGO syntax is very simple. Enter the chmod command and then the users you want to change permissions for, providing u for user, g for group, or o for others, followed by one of three operators:
- Removes a permission
+ Adds a permission
= Sets a permission
After the operator, include the permission you want to add or remove (rwx) and, finally, the name of the file to apply it to.
So, if you want to remove the write permission from the user that the file hashcat.hcstat belongs to, you could enter the following:
kali >chmod u-w hashcat.hcstat
This command says to remove (-) the write (w) permission from hashcat.hcstat for the user (u).
Now when you check the permissions with ls –l again, you should see that the hashcat.hcstat file no longer has write permission for the user:
kali >ls -l
total 32952
drwxr-xr-x 5 root root 4096 Dec 5 10:47 charsets
-r-xr-xr-- 1 root root 33685504 June 28 2018 hashcat.hcstat
-rw-r--r-- 1 root root 33685504 June 28 2018 hashcat.hctune
drwxr -xr-x 2 root root 4096 Dec 5 10:47 masks
drwxr -xr-x 2 root root 4096 Dec 5 10:47 OpenCL
drwxr -xr-x 3 root root 4096 Dec 5 10:47 rules
You can also change multiple permissions with just one command. If you want to give both the user and other users (not including the group) execute permission, you could enter the following:
chmod u+x, o+x hashcat.hcstat
This command tells Linux to add the execute permission for the user as well as the execute permission for others for the hashcat.hcstat file.
As a hacker, you’ll often need to download new hacking tools, but Linux automatically assigns all files and directories default permissions of 666 and 777, respectively. This means that, by default, you won’t be able to execute a file immediately after downloading it. If you try, you’ll usually get a message that says something like “Permission denied.” For these cases, you’ll need to give yourself root and execute permissions using chmod in order to execute the file.
For example, say we download a new hacker tool called newhackertool and place it into the root user’s directory (/).
kali >ls -l
total 80
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Desktop
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Documents
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Downloads
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Music
-rw-r--r-- 1 root root 1072 Dec 5 11.17 newhackertool➊
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Pictures
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Public
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Templates
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Videos
We can see newhackertool at ➊, along with the rest of the contents of the root directory. We can see that our newhackertool doesn’t have execute permission for anyone. This makes it impossible to use. It might seem strange that by default, Linux won’t let you execute a file you downloaded, but overall this setting makes your system more secure.
We can give ourselves permission to execute newhackertool by entering the following:
kali >chmod 766 newhackertool
Now, when we perform a long listing on the directory, we can see that our newhackertool has execute permission for the owner:
kali >chmod 766 newhackertool
kali >ls -l
total 80
--snip--
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Music
-rwxrw-rw- 1 root root 1072 Dec 5 11.17 newhackertool
drwxr-xr-x 7 root root 4096 Dec 5 11.17 Pictures
--snip--
As you now understand, this grants us (as the owner) all permissions, including execute, and grants the group and everyone else only read and write permissions (4 + 2 = 6).
As you have seen, Linux automatically assigns base permissions—usually 666 for files and 777 for directories. You can change the default permissions allocated to files and directories created by each user with the umask (or unmask) method. The umask method represents the permissions you want to remove from the base permissions on a file or directory to make them more secure.
The umask is a three-digit decimal number corresponding to the three permissions digits, but the umask number is subtracted from the permissions number to give the new permissions status. This means that when a new file or directory is created, its permissions are set to the default value minus the value in umask, as shown in Figure 5-1.
Figure 5-1: How a umask value of 022 affects the permissions on new files and directories
For example, if the umask is set to 022, a new file with the original default permissions of 666 will now have the permissions 644, meaning the owner has both read and write permissions, and the group and all other users have only read permission.
In Kali, as with most Debian systems, the umask is preconfigured to 022, meaning the Kali default is 644 for files and 755 for directories.
The umask value is not universal to all users on the system. Each user can set a personal default umask value for the files and directories in their personal .profile file. To see the current value when logged on as the user, simply enter the command umask and note what is returned. To change the umask value for a user, edit the file /home/username/.profile and, for example, add umask 007 to set it so only the user and members of the user’s group have permissions.
In addition to the three general-purpose permissions, rwx, Linux has three special permissions that are slightly more complicated. These special permissions are set user ID (or SUID), set group ID (or SGID), and sticky bit. I’ll discuss each in turn in the next three sections.
As you should know by now, a user can execute a file only if they have permission to execute that particular file. If the user only has read and/or write permissions, they cannot execute. This may seem straightforward, but there are exceptions to this rule.
You may have encountered a case in which a file requires the permissions of the root user during execution for all users, even those who are not root. For example, a file that allows users to change their password would need access to the /etc/shadow file—the file that holds the users’ passwords in Linux—which requires root user privileges in order to execute. In such a case, you can temporarily grant the owner’s privileges to execute the file by setting the SUID bit on the program.
Basically, the SUID bit says that any user can execute the file with the permissions of the owner but those permissions don’t extend beyond the use of that file.
To set the SUID bit, enter a 4 before the regular permissions, so a file with a new resulting permission of 644 is represented as 4644 when the SUID bit is set.
Setting the SUID on a file is not something a typical user would do, but if you want to do so, you’ll use the chmod command, as in chmod 4644 filename.
SGID also grants temporary elevated permissions, but it grants the permissions of the file owner’s group, rather than of the file’s owner. This means that, with an SGID bit set, someone without execute permission can execute a file if the owner belongs to the group that has permission to execute that file.
The SGID bit works slightly differently when applied to a directory: when the bit is set on a directory, ownership of new files created in that directory goes to the directory creator’s group, rather than the file creator’s group. This is very useful when a directory is shared by multiple users. All users in that group can execute the file(s), not just a single user.
The SGID bit is represented as 2 before the regular permissions, so a new file with the resulting permissions 644 would be represented as 2644 when the SGID bit is set. Again, you would use the chmod command for this—for example, chmod 2644 filename.
The sticky bit is a permission bit that you can set on a directory to allow a user to delete or rename files within that directory. However, the sticky bit is a legacy of older Unix systems, and modern systems (like Linux) ignore it. As such, I will not discuss it further here, but you should be familiar with the term because you might hear it in the Linux world.
As a hacker, these special permissions can be used to exploit Linux systems through privilege escalation, whereby a regular user gains root or sysadmin privileges and the associated permissions. With root privileges, you can do anything on the system.
One way to do this is to exploit the SUID bit. A system administrator or software developer might set the SUID bit on a program to allow that program access to files with root privileges. For instance, scripts that need to change passwords often have the SUID bit set. You, the hacker, can use that permission to gain temporary root privileges and do something malicious, such as get access to the passwords at /etc/shadow.
Let’s look for files with the SUID bit set on our Kali system to try this out. Back in Chapter 1, I introduced you to the find command. We’ll use its power to find files with the SUID bit set.
As you’ll remember, the find command is powerful, but the syntax is bit more complicated than some of the other location commands, such as locate and which. Take a moment to review the find syntax in Chapter 1, if you need to.
In this case, we want to find files anywhere on the filesystem, for the root user or other sysadmin, with the permissions 4000. To do this, we can use the following find command:
kali >find / -user root -perm -4000
With this command, we ask Kali to start looking at the top of the filesystem with the / syntax. It then looks everywhere below / for files that are owned by root, specified with user root, and that have the SUID permission bit set (-perm -4000).
When we run this command, we get the output shown in Listing 5-2.
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/pkexec
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/kismet_capture
--snip--
Listing 5-2: Finding files with the SUID bit set
The output reveals numerous files that have the SUID bit set. Let’s navigate to the /usr/bin directory, where many of these files reside, and then run a long listing on that directory and scroll down to the sudo file, as shown in Listing 5-3.
kali >cd /usr/bin
kali >ls -l
--snip--
-rwxr-xr-x 1 root root 176272 Jul 18 2018 stunnel4
-rwxr-xr-x 1 root root 26696 Mar 17 2018 sucrack
➊ -rwsr-xr-x 1 root root 140944 Jul 5 2018 sudo
--snip--
Listing 5-3: Identifying files with the SUID bit set
Note that at ➊, the first set of permissions—for the owner—has an s in place of the x. This is how Linux represents that the SUID bit is set. This means that anyone who runs the sudo file has the privileges of the root user, which can be a security concern for the sysadmin and a potential attack vector for the hacker. For instance, some applications need to access the /etc/shadow file to successfully complete their tasks. If the attacker can gain control of that application, they can use that application’s access to the passwords on a Linux system.
Linux has a well-developed system of security that protects files and directories from unauthorized access. The aspiring hacker needs to have a basic understanding of this system not only to protect their files but also to execute new tools and files. In some cases, hackers can exploit the SUID and SGID permissions to escalate privileges from a regular user to a root user.
Linux’s use of permissions to protect a user’s or group’s files and directories from other users in the system can be used for offensive and defensive purposes. You should now know how to manage these permissions and how to exploit weak points in this security system—in particular, SUID and SGID bits.
