How to use the capability feature to enhance the security of Linux systems

Abstract: The access control model of traditional UNIX systems is very simple - ordinary users to super users. In this model, a process or account has either a small privilege or all system privileges. Obviously, this is not good for the security of the system. Starting with the Linux-2.1 kernel, the concept of capability was introduced to achieve finer-grained access control.

1. Introduction

UNIX is a secure operating system
, which gives ordinary users the lowest possible permissions, and gives 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/unmount file systems, manage users, install software, and more. In addition, many operations of ordinary users also require root privileges, which is achieved by setuid.

This way of relying on a single account to perform privileged operations increases the risk of the system, and programs that require root privileges may be for a single operation, such as binding to a privileged port, opening a root only Permissions can access files. Some programs may have security vulnerabilities, and if the program does not run as root, its vulnerabilities may not pose any threat to the system.

Starting with version 2.1, kernel developers have added the concept of capabilities to the Linux kernel. The goal is to eliminate the dependency of the program that needs to perform certain operations on the root account. Starting with the 2.2 kernel, these generations are basically usable, although there are still some problems, but the direction is correct.

2. Detailed Linux kernel capabilities

The traditional UNIX trust model is very simple, that is, "super user vs. ordinary user" model. In this model, a process can do anything or almost nothing, depending on the UID of the process. Full root privileges are required if a process needs to perform operations such as binding to a private port, loading/unloading kernel modules, and managing file systems. Obviously, this poses a great threat to system security. The SUID problem in UNIX systems is caused by this trust model. For example, a normal user needs to use the ping command. This is a SUID command that will run with root privileges. In fact, this program only needs RAW sockets to establish the necessary ICMP packets, and other root privileges are unnecessary for this program. If the program is not well written, it may be exploited by the attacker to gain control of the system.

Capability can reduce this risk. The system administrator can deprive the root user of the system's security, so that even the root user will not be able to perform certain operations. This process is irreversible, which means that if a capability is removed, the root user cannot re-add the deleted capability unless the system is restarted.

2.1. The concept of capabilities

The concept of capabilities used in the Linux kernel is very confusing. A wide variety of capabilities are defined in computer science. A capability is an operation that a process can perform on an object, it flags the object and the operations that are allowed on that object. File descriptor is a capability, you use the open system call request to get read or write permission, if the open system call is successful, the system's 诤 峤 峤 (14) 桓 枋龇 枋龇 枋龇 螅绻盏 螅绻盏 螅绻盏 螅绻盏 螅绻盏 螅绻盏 螅绻盏 螅绻盏肭螅诤司褂褂谜飧 Xin 枋龇魑桓鍪萁峁 枋龇魑桓鍪萁峁 饕焖飨喙氐牟 饕焖飨喙氐牟 饕焖飨喙氐牟 饕焖飨喙氐牟 饕焖飨喙氐牟 饕焖飨喙氐牟 饕焖飨喙氐牟 魇 魇 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢 恢The call is, the kernel establishes the necessary data structure at one time, and then the operation check such as reading and writing only needs to be in the data structure. Operations on capabilities include: replication capabilities, ability to move between processes, modifying an ability, and undoing a capability. Modifying a capability is similar to changing a file descriptor that can be read or written to read-only. At present, the degree of application of capabilities to various systems is not the same.

POSIX 1003.1e also proposes a capability definition, commonly referred to as POSIX capabilities, which is not the same as defined in Linux. The kernel uses these capabilities to split root privileges because root permissions are too powerful in traditional *NIX systems.

2.2. How Linux uses POSIX capabilities instead of traditional credential models

Each process has three capability-dependent bitmaps: inheritable(I), permitted(P), and effective (E), corresponding to the cap_effective, cap_inheritable, cap_permitted in the process descriptor task_struct(include/linux/sched.h). Each capability is represented by one bit, with 1 indicating a certain ability and 0 indicating no. When a process wants to perform a privileged operation, the operating system checks whether the corresponding bit of cap_effective is valid, instead of checking whether the valid UID of the process is 0. For example, if a process wants to set the system clock, the Linux kernel will check if the cap_effective CAP_SYS_TIME bit (bit 25) is valid.

cap_permitted indicates the ability of the process to be used. Cap_permitted can contain capabilities that are not available in cap_effective. These capabilities are temporarily discarded by the process itself. It can also be said that cap_effective is a subset of cap_permitted. The process of abandoning unnecessary capabilities is a great help for improving security. For example, ping only requires CAP_NET_RAW, and if it abandons other capabilities than this, even if there are security flaws, it will not cause too much damage to the system. Cap_inheritable represents the ability to be inherited by a program executing by the current process.

3. Linux Supported Capabilities

Linux implements seven POSIX 1003.1e stipulation capabilities, and 21 (as of 2.4.7-10 version of the kernel) are unique to Linux. These capabilities are defined in the /usr/src/linux/include/linux/capability.h file. The details are as follows:

Capability Name Number Description CAP_CHOWN 0 Allows changing the ownership of the file CAP_DAC_OVERRIDE 1 Ignore all DAC access restrictions on the file CAP_DAC_READ_SEARCH 2 Ignore all restrictions on read and search operations CAP_FOWNER 3 If the file belongs to the UID of the process , Cancel the restriction on the file CAP_FSETID 4 Allows the setuid bit to be set CAP_KILL 5 ​​Allows the signal to be sent to the process that does not belong to itself CAP_SETGID 6 Allows to change the group ID CAP_SETUID 7 Allows to change the user ID CAP_SETPCAP 8 Allows the transfer of capabilities to other processes and the deletion of other processes Capability CAP_LINUX_IMMUTABLE 9 Allows modification of the file's non-modifiable (IMMUTABLE) and only add (APPEND-ONLY) attributes CAP_NET_BIND_SERVICE 10 Allows binding to ports less than 1024 CAP_NET_BROADCAST 11 Allows network broadcast and multicast access CAP_NET_ADMIN 12 Allows execution of network management tasks: interface, Firewall and routing, etc. For details, please refer to /usr/src/linux/include/linux/capability.h file CAP_NET_RAW 13 Allow the use of raw socket CAP_IPC_LOCK 14 Allow to lock shared memory fragment CAP_IPC_OWNER 15 Ignore IPC ownership check CAP_SYS_MODULE 16 Insert and delete kernel module CAP_SYS_RAWIO 17 Allow access to ioperm/iopl CAP_SYS_CHROOT 18 Allow chroot() system call CAP_SYS_PTRACE 19 Allow tracking of any process CAP_SYS_PACCT 20 Allow process accounting CAP_SYS_ADMIN 21 Allow Perform system administration tasks: load/unmount file systems, set disk quotas, turn on/off switching devices and files, and more. Please refer to the /usr/src/linux/include/linux/capability.h file for details.