A fundamental understanding of authorization and access control is vital for IT specialists, sysadmins, and users. In this article, I’ll explain what authorization is and walk through an example of access control using Linux filesystem permissions.
For this article, it will be helpful to have a basic understanding of authentication as well. If you are not familiar with that concept or need a refresher, you may want to read Authentication Basics first.
What is Authorization?
Whereas authentication is the process of verifying who you are, authorization defines what you are allowed to do (e.g., login, read, write, or delete files). I’ll explain the concept of authorization with two examples.
Visitor Pass and Speaker Pass
For this first example, suppose you are attending an event, such as an open source conference or a Linux Day with talks about different topics.
Usually for these events, different kinds of passes exist. For example, there is typically a visitor or attendee pass. If you hold this pass, you are authorized to enter the event, listen to talks, join workshops, and visit the fair or exhibition, if applicable. This pass, however, would not allow you to enter the backstage area where speakers could rest and prepare for their talks. Authorization to enter these restricted areas would require a speaker pass.
So, there are different kinds of passes, and certain permissions are mapped to these passes. Determining which access or actions are permitted with a certain pass is the process of authorization.
Linux Users with Different Permissions
Next, let’s consider the example of user permissions. As a regular user, you may be authorized to login to a certain Linux host. Furthermore, you may be allowed to use a shell, read, write, or delete files in your HOME directory and /tmp, and so on. But, with this level of permission, you may not alter files belonging to other users or root.
The root user, on the other hand, is allowed to do almost everything. It’s the user account with the highest privileges on a Linux system.
User entities are also called subjects in the context of authorization and do not necessarily equal to human users, because human users can switch entities, for example, when a regular Linux user like Alice becomes root by using sudo -i.
Resources like files, devices, or inodes that can be accessed by subjects are called objects. Access control models are used to determine what subjects are allowed to do, and I will cover those in the next section.
Access Control Models
Again, access control models are used to determine what objects subjects are allowed to access and which operations they are allowed to perform on them. These models are divided into capability-based and ACL-based models, where ACL is short for Access Control List.
Capability-Based Access Control
In this model, the subject holds an unforgeable reference or capability to an object that provides access to it. For example, this could be the private SSH key that’s being used to access a system where the public SSH key is present in a user’s authorized_keys file.
Another example would be the password that is needed to decrypt an encrypted file in order to access it. To grant other subjects access to this file, you have to transmit this shared secret through secure channels to the subjects in question.
Access Control Lists
In this model, a subject's access to an object depends on whether their identity appears on a list associated with the object. For example, if you wish to attend a private party, your name must be on the guest list in order to gain entrance.
In another example within the context of computer systems, suppose the user Bob wants to edit a file called file.txt. To be able to do so, Bob must be on a list associated with file.txt that specifies that Bob is allowed to access and modify this object.
The following code block shows what this might look like in a Linux filesystem, showing the listing of a single directory called testdir:
~~~ alice@host:~$ ls -ld testdir drwxr-xr-x 2 root root 4096 Jul 16 12:41 testdir ~~~
The second line contains a lot of information and requires additional explanation. This line shows seven columns, which correlate to the following information:
drwxr-xr-x :Specifies file type and permissions2 :Number of hard-linksroot :Owner of this objectroot :To which group this object belongs4096 :Object’s size in bytesJul 16 12:41 :Creation/modification date and timetestdir :Directory/file name
In this context, only the columns 1, 3, 4, and 7 are of interest, however, and I will look at each in turn.
The first column shows drwxr-xr-x. Here, the first character has nothing to do with the permissions, which leaves three blocks of triads. The first triad, rwx, specifies the permissions of the file’s owner (root in this case). The second triad, r-x, determines the permissions for users who are members of the group (there is a group named root here). And last but not least the third triad, r-x, with the permissions of all others.
The rwx in the first triad means that the owner is allowed to (r)ead, (w)rite, and e(x)ecute this object. The second and third triads with r-x specify that members of the group root as well as all others are allowed to (r)ead and e(x)ecute the object, which means that these subjects are able to list the directory’s content and enter the directory.
Alice is not a member of the group root, but because of the third triad, she is authorized to list the directory’s entries and to enter it:
~~~ alice@host:~$ ls -l testdir -rw-r--r-- 1 alice alice 13 Jul 16 12:37 hello_world.txt alice@host:~$ cd testdir/ alice@host:~/testdir$ ~~~
The directory contains a file named hello_world.txt owned by alice and a group called alice belonging to it. Only the user alice is allowed to read and write to this file. Members of the group alice and all others are authorized to read it.
Note: In Linux, it’s common to have a group for each user that has the same name as the user itself. It’s possible that the users Bob and Charlie may belong to the group alice and are therefore able to read the contents of the file hello_world.txt, too.
Now, of all permissions from the third triad of testdir are removed, Alice won’t be able to access the directory anymore, because she is not a member of the group nor the owner of the directory:
~~~ alice@host:~$ ls -ld testdir/ drwxr-x--- 2 root root 4096 Jul 16 12:41 testdir/ alice@host:~$ cd testdir bash: cd: testdir: Permission denied ~~~
Alice is not able to access the file hello_world.txt anymore that’s inside the directory testdir, because she has lost access to the directory itself.
Wrapping Up
In this article, we explained what authorization is and how it differs from authentication. We gave examples for authorization processes and explained the two different access control models: capability-based access control and access control lists.
The Linux/UNIX file permissions were used to show an example of how ACLs could be used. Note that, although Linux/UNIX file permissions are a type of ACL, they are not to be confused with the POSIX ACL, which are also available on Linux platforms. S acl(5) in the man pages for more information.
We learned that authorization is used to determine what actions a subject is allowed to perform on an object. Besides the examples from this article, other methods can be used to implement access control, including Discretionary Access Control (DAC), Mandatory Access Control (MAC) or Role-Based Access Control (RBAC), to name the most common ones.
Looking for a job?
Sign up for job alerts and check out the latest listings at Open Source JobHub.
Comments