Skip to content

Permissions

Before we get going with Privesc, lets have a quick recap of permissions. Hopefully this is just a recap, so feel free to skip over it if you know this. We will have a quick reference at the end of the article.

Authentication and Authorisation

When it comes to user access we have two main components

Authentication

Is the process of confirming a User is who they say they are. This comes up in almost all computer, and physical systems. Authentication tends to rely on the user supplying some "secret" information that only they know. For example, a password, or bio-metric.

The most common example of this is a password. Before we allow a user to access the system, we prompt them for the password. If this is only known to the user, then we can be sure that whoever supplies the correct authentication information is who they say they are.

Authorisation

The other side to our access control is authorisation. This sets out the level of access to systems, services or files for an authorised user.

For example, we can allow an authenticated Admin user access to system files that are not accessible to standard users.

With a combination Authentication and Authorisation we can have a fine level of control over security. However, both need to be considered together. Without properly authenticating a user, then the authorisation settings are useless. Similarly, not applying the appropriate authorisation, means that users may be able to access files they shouldn't be able to.

Permissions in Linux

Unix based systems (including Mac-OS, BSD, and Linux) give us a good level of control over permissions. These permissions are based on the two factors discussed above. Authentication (who can access the file), and Authorisation (what they can do with it)

Permission Groups (Authentication)

We can break the permission groups into 3 sets of users. Each file or directory will have separate permission levels for:

  • Owner: A specific user that is the Owner of the file
  • Group: A second "Group" of users that can have a different level of access.
  • World: Finally, every user on the system

The "Highest" level of permissions for a given user applies. Therefore, if a user is in the Group its permissions take precedence over the World.

Permission Types (Authorisation)

There are also three types of access rights.

  • Read: A user with this right can read the contents of the file.
  • Write A user with this right can modify the contents of the file
  • Execute A user with this right can execute the contents of the file.

These permission levels work slightly differently for directories. Its easier to think of this case as a list

  • Read means you can read the list. (ie read the files in the dir)
  • Execute means you can enter the directory.
  • Write means you can modify files in the dir. BUT you need Execute privileges too.

This can lead to some weirdness.

Having Read access will let you list the files in the dir, BUT ls -l wont supply any information.

# So with Read perms on the Directory
dang@dang-laptop /tmp$ ls -l 
dr--r--r-- 2 root root  80 Feb  5 22:20 Testing

#We can still List the contents
dang@dang-laptop /tmp$ ls -l Testing
ls: cannot access 'Testing/bar': Permission denied
ls: cannot access 'Testing/foo': Permission denied
total 0
-????????? ? ? ? ?            ? bar
-????????? ? ? ? ?            ? foo

# But can't access the dir
dang@dang-laptop /tmp$ cd Testing
cd: permission denied: Testing

Having Only Execute rights will let you CD into the directory, But you will be unable to list its contents, using ls. However, if you have permissions for any of the files in the directory, you will be able to access them, even though you cant list them.

Finally, Execute and Write permissions on the directory, we can modify files within the directory, but not their contents, or permissions. For example, we can rename files.

Hint

To see this in action go back to level 18 of the Linux trainer, as well as the SUID based privesc, we can also simply change the permission of the file, even though we don't actually have any rights on the file itself.

So we could just mv Pass.txt File.txt

"Special" Permissions

There are also two extra permission bits that can be set.

  • The Sticky bit, lets only the owner of the file or directory (or root) delete or rename a file.
  • The SUID bit allows another user to execute the program as the Owner or Group of the file. We will get into this in more detail later, but it gives one of our ways of privesc.

Discuss

Would the Sticky bit help in Level18 of the Linux trainer? What is happening with the directory / file permissions to make this happen.

Showing Permissions

As you know from the first year, Permissions are represented via a Bit-mask. We can see the permissions allocated to a file using the ls -l command.

Permissions

Modifying Permissions

WE can modify permissions in two ways, using the chmod command

  1. Numerical Value. (the "old fashioned" way). Here we specify the new permission string as 3 Bits, For example 777 gives RWX to all users, 744 is RWX for the user and R for both group and world users.

    Here we need to use the value of the bitmask:

    • R == 4
    • W == 2
    • X == 1

  2. Text based:

    We can also assign permissions using text. Here we combine the values we want to add into a string.

    For example:

    • chmod a+x Gives All users eXecute rights
    • chmod u+w Gives the User Write permission

Summary

In this page we have given an overview of Linux permission settings, looking at the different forms of authorisation and authentication available. We have examined the different "roles" that can be assigned through permissions, and the different access levels that can be granted.

In the next article we will take a brief detour into Windows based permissions, before coming back and looking at some more advanced (and less common) permissions settings in Linux

Back to top