Enhancing Linux Security: Understanding Capabilities to Reduce Root Account Risks

0x1 Background Knowledge on Adding Linux Capabilities

Linux is a secure operating system that provides ordinary users with the lowest possible permissions while assigning all system privileges to a single account—root. The root account is used to manage the system, install software, manage accounts, run certain services, install/uninstall file systems, manage users, and install software. Additionally, many ordinary user operations require root privileges, which are implemented through setuid.

This reliance on a single account to perform privileged operations increases the risk to the system, whereas programs that require root privileges may need them only for a single operation, such as binding to a privileged port or opening a file accessible only by root. Certain programs may have security vulnerabilities, and if they are not running with root privileges, these vulnerabilities might not pose any threat to the system.

Starting with version 2.1, kernel developers introduced the concept of capabilities in the Linux kernel. The goal is to eliminate the dependency of programs requiring certain operations on the root account. From kernel version 2.2 onwards, these capabilities are mostly usable, although there are still some issues, but the direction is correct.

0x2 Introduction to Kernel Capabilities

The traditional UNIX trust model is straightforward: a “superuser-versus-ordinary user” model. In this model, a process can either do everything or almost nothing, depending on the process’s UID. When a process needs to perform operations like binding to private ports, loading/unloading kernel modules, and managing file systems, it requires full root privileges. Clearly, this poses a significant threat to system security.

The SUID problem in UNIX systems is caused by this trust model. For example, an ordinary user needs to use the ping command. This is a SUID command that runs with root privileges. However, this program only requires RAW socket access to establish the necessary ICMP packets, and no other root privileges are necessary. If the program is poorly written, it can be exploited by attackers to gain control of the system.

Using capabilities can reduce this risk. System administrators can remove certain capabilities from the root user for system security, and then even the root user will not be able to perform certain operations. This process is irreversible, meaning that once a capability is removed, even the root user cannot re-add it without rebooting the system.

The main idea behind capabilities is to divide root privileges into different capabilities, each representing a certain privileged operation. For example, the capability CAP_SYS_MODULE means a user can load (or unload) kernel modules, while CAP_SETUID means a user can change the user identity of a process. In capabilities, the system controls privileged operations based on the capabilities the process possesses.

In capabilities, only processes and executable files have capabilities, and each process has three sets of capabilities, known as cap_effective, cap_inheritable, and cap_permitted (abbreviated as: pE, pI, pP).

The system controls access based on the cap_effective set of the process, with cap_effective being a subset of cap_permitted. A process can relinquish some privileges by removing certain capabilities from cap_effective.

Executable files also have three sets of capabilities corresponding to a process’s sets: cap_effective, cap_allowed, and cap_forced (abbreviated as fE, fI, fP).

0x3 Implementation Mechanism of Capabilities in the Linux Kernel

Starting with version 2.2, Linux introduced the concept and mechanism of capabilities, which have been progressively improved as the version increases. In Linux, root privileges are divided into 29 capabilities:

These capabilities can be individually added as options to the three capability sets of a process, providing more flexibility for program privilege control.

0x4 The Issue of Running Wireshark Without Root Privileges

Launching Wireshark for the first time in Linux might feel strange because no network interface cards like eth0 are visible. This is because accessing these devices directly requires root privileges. I used root privileges to do it, which is not advisable. For instance, Gentoo warns: WIRESHARK CONTAINS OVER ONE POINT FIVE MILLION LINES OF SOURCE CODE. DO NOT RUN THEM AS ROOT.

So, what should be done? Wireshark’s leader, Gerald Combs, points out that most Linux distributions are now implementing filesystem permissions (capabilities) for using raw network devices, allowing Wireshark to be launched by ordinary users.

The specific method is as follows:

However, what does the suffix eip represent in the command below?

As mentioned earlier, it represents the three sets of capabilities for a process.