Filesystem Permissions

Wrong permissions on files may lead to someone doing what they should not be allowed to

Regular Permissions

When running the ls command to see files in a directory, you can provide the -l flag to list all information about the file as well. Together with -a to see all files (including ones starting with a . dot), you get a common command to see file permissions and other information:

Using the ls command to see file permissions

Here there are different columns with different purposes. The first column shows the permissions for the file or directory, depending on how much you are related to the item. This is about the owner and group of the file. To the right of the permissions, there are 2 names, the user and the group owner. Different permissions apply to the owner or group of the file than other users on the system.

The first yellow letter in the permissions shows the type, either d for a directory or - for a regular file. Then there are 3 pairs of 3 letters.

r = read w = write x = execute

The first green pair shows the user permissions. The second blue pair shows the group permissions, and finally, the last red pair shows everyone else's permissions, that aren't the user or group owner.

This allows separate permissions for the owner, group, and everyone else. A - dash means the permission that should be in that spot is not given. You could for example make a file readable, but not writable or executable with a r-- permission.

Note: For directories, these rwx permissions mean something slightly different:

r = read -> list files inside w = write -> create files inside x = execute -> travel inside with cd

Something not yet covered is the s permission that you might see instead of x. This is a special permission meaning setuid. When this bit is set, and you can execute it, you will gain the rights of the program owner while executing the program. This means if the program has any functionality to read files, for example, you can read files with the rights of the program owner.

This sounds dangerous because it is. Only very few programs actually require this, like sudo for example to give you higher permissions only if you put in the correct password first. For more information on this see SetUID.

Chmod

chmod is short for "change file mode bits", as these permissions are also known as mode bits. This tool allows you to change the permissions of a file. The syntax to do so might take some getting used to, but it works as follows.

You take the permissions for the 3 pairs and convert them to a binary number representing which permissions you want to give, and the ones you don't. Then convert this binary number to decimal, and you get a string of 3 numbers as follows:

This command above would mean the files is readable, writable, and executable by the owner, not writable by the group, and for everyone is it only executable. There are some more common file permissions you might want to set, for example:

• 600 (rw- rw- ---): Only readable or writable by owners of the file

• 777 (rwx rwx rwx): Everyone can do anything with the file

Different syntax

Some more useful syntax you might see is using the + symbol in the mode bits, followed by a permission. This is some short syntax to add the permission to the bits if it wasn't already there. Without further specification, it will apply the permission to all 3 pairs.

rw- rw- r--
$ chmod +x file  # Add executable permission for everyone
rwx rwx r-x
$ chmod +s file  # Add setuid permission to user and group owner
rws rws r-x

You can also specify with the user (u), group (g) or other users (o) what permissions you need exactly without having to think about the binary numbers. Simply prefix one of these letters before the permission to only apply it there.

rw- rw- r--
$ chmod u+x file  # Add executable permission for the user owner
rwx rw- r--
$ chmod o+rwx file  # Add all permissions for other users
rwx rw- rwx

Access Control List (ACL)

Sometimes you might see a + plus symbol after the permissions of a file/directory in ls -l. This means it has additional, more specific permissions that might be abusable. To view these permissions, use the getfacl command:

$ getfacl -t file.txt
USER   root      rwx
user   john      rw-
GROUP  root      rwx
mask             rwx
other            r--

Here the -t argument gives a simpler layout of the results. You can see the USER, GROUP, and other permissions that ls -l already gives, as well as the additional permission: user john rw-. This is interesting because it means the user john, who is not the owner of the file, still has write permissions, while other users can only read.

You can find all files with extra ACL permissions with the following recursive command:

$ getfacl -R -s -t / 2>/dev/null

In a default system, these permissions are rarely used, so any results may be worth checking out.

Hidden Permissions

In specific scenarios, you might find some automated functionality that tries to check if some file or directory is protected enough that you should not have write access. It can do so by checking if you aren't the user or group owner, and if the w bit is not set for other users. It might think this is enough, but using ACLs you can create extra specific permissions that go further than just bits, possibly fooling the check.

Setting permissions is done using the setfacl command. Here are some of the important flags:

• -m: Modify (overwrite) permissions

• -x: Remove permissions

• -b: Remove all ACL entries

• -d: Set default ACLs

After the flag comes the entry itself. The format is [type]:[uid/gid]:[perms]:

• User: u:hacker:rwx

• Group: u:hackergroup:rwx

If we wanted to create a backdoor of sorts where it looks like we shouldn't have permissions, but due to ACLs we can still write, we can add our user with rwx rights:

$ sudo setfacl -m u:hacker:rwx dir/
$ ls -l
drwxrwx 2 root root 4096 Jul  8 09:03 dir

Capabilities

A different way administrators can give more privileges to a binary is through capabilities. Especially the cap_setuid is very interesting because similar to the SetUID bit, it executes a program as another user.

Finding capabilities

To get all your capabilities as a user, use the getcap command. It will give a lot of errors, so just redirect them to null to get a clean output. Note that this command can take a bit because it looks through the whole system.

getcap -r / 2>/dev/null

To only get setuid capabilities you can filter it with grep:

getcap -r / 2>/dev/null | grep cap_setuid

Exploiting capabilities

After finding binaries with special capabilities, you can look them up on GTFOBins to see if any functionality is exploitable:

GTFOBins

GTFOBins, a searchable list of exploitable binaries

Then just use a command you find there to get higher privileges. Since the cap_setuid capability is the same as the SetUID bit on a file, you can use the same exploitation ideas from there.

Another capability you might find is cap_net_raw,cap_net_admin=eip on tcpdump specifically. This is so that it can use the raw packet intercepting it needs, but can also allow anyone on the system to use it without needing root permissions. While this might be the intended behavior, an attacker can exploit this by intercepting traffic containing passwords or other sensitive information.