Introduction

In this series, we will be looking at Linux capabilities and how we can use them to run create more secure computing environments. In this particular post, we will go through an introduction of Linux capabilities and how their use compares with the traditional privilege model.

Traditional Model

Before Linux kernel 2.2, the Linux privilege model typically made a binary decision as a first instance to decide if a process has the required privileges to run a program.

If the Effective User ID (EUID) of the process was 0. This means the effective user is root or a superuser. This user bypassed all other forms of checks and the process ris allowed to run the application. If the EUID is not 0, the process is subjected to other checks such as an examination of the

• privileges held by the EUID of the process.
• privileges held by the Effective Group ID (EGID)
• privileges held by the supplementary groups the user intending to run the process belongs to.

Enter Linux Capabilities

Capabilities are a fine-grained approach to privileges and access control permissions. This is at variance to the all-or-nothing approach of the traditional model where a process needs to run as a super user of some form in other to perform its function. The privileged activities on a system are divided into distinct units with each capability holding a subset of activities.

With this model, a process just needs the exact capability it requires to perform the activity it needs. For instance a process that needs to change the system time merely requires the CAP_SYS_TIME capability. It is not required to run as a root user. This scheme allows the security principle of least privilege and also ensures that a compromise of the process carries a lower exposure surface compared to the traditional model.

It is also worth nothing that the capabilities definitions are not set in stone. It is an area where fine-tuning is constantly ongoing to enforce the principle of least privilege - enabling a process to be granted just the required privilege it requires to perform its tasks and no more.

The CAP_SYS_ADMIN is one such capability that has undergone a number of refinements to reduce the privileges it held. This is to make sure it isn't used as a defacto superuser capability. If you built a service or ran a container that made use of the CAP_SYS_ADMIN capability prior to kernel 5.8. You will find that if the process was meant to perform Berkeley Packet Filters (BPF) or performance monitoring tasks, those tasks won't succeed in kernel 5.8. This is because CAP_BPF and CAP_PERFMON have been created to take the BPF and performance monitoring functions respectively away from CAP_SYS_ADMIN.

The capabilities supported on a system and the privileges that accompany them can be checked by viewing the Linux manual pages.

man 7 capabilities

In the next post in the series, we will be looking at the practical applications of capabilities.