Use capability features to enhance Linux System Security

Abstract: The Access Control Model for traditional UNIX systems is very simple-for common users, Super Users. In this model, a process or account has either very small permissions or all system permissions. Obviously, this is of no benefit to system security. Starting from the Linux-2.1 kernel, the concept of capacity is introduced to achieve more fine-grained access control.

1. Introduction

UNIX is a secure operating system that gives ordinary users as low permissions as possible, and gives all system permissions to a single account-root. Root accounts are used to manage systems, install software, manage accounts, run certain services, install/uninstall file systems, manage users, and install software. In addition, many operations of common users also require the root permission, which is implemented through setuid.

This method of relying on a single account to perform privileged operations increases the risk of the system, and the program that requires root permissions may only be used for a single operation, for example: bind to a privileged port and open a file that only has the root permission to access. Some programs may have security vulnerabilities. If a program does not run with root permissions, its existing vulnerabilities cannot pose any threat to the system.

Starting from version 2.1, kernel developers have added the capability concept to the Linux kernel. The goal is to eliminate the dependency of programs that require certain operations on the root account. Starting from kernel 2.2, these generations are basically usable. Although there are still some problems, the direction is correct.

2. Linux kernel capabilities

The traditional UNIX trust model is very simple, that is, the "Super User to common user" model. In this model, a process can either do anything or almost nothing, depending on the UID of the process. If a process needs to bind to a private port, load/uninstall the kernel module, and manage the file system, it requires full root permissions. Obviously, this poses a great threat to system security. The SUID problem in UNIX systems is caused by this trust-like model. For example, a common user needs to use the ping command. This is a SUID command that runs with the root permission. In fact, this program only requires RAW sockets to establish necessary ICMP data packets. Other root permissions are not necessary for this program. If the program is not well written, attackers may exploit it 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 cannot perform some operations. This process is irreversible. That is to say, if a capability is deleted, the deleted capability cannot be re-added even if the root user restarts the system.

2. 1. Concept of capabilities

The capabilities used in the Linux kernel are very confusing. Many Capabilities are defined in computer science ). A process can perform operations on an object. It marks the object and allows operations on the object. A file descriptor is a capability. You can use an open system call request to obtain read or write permissions. If the open system call succeeds, the system's zookeeper, Zookeeper, and zookeeper. it is called by the system of the zookeeper, Zookeeper, Zookeeper, and zookeeper, which is not in the U region of the United States, the kernel establishes the necessary data structure at one time, and then performs read/write operations such as checking by shuttle in the data structure. Operations on capabilities include: Replication capability, inter-process migration capability, modification capability, and withdrawal capability. The ability to modify a file descriptor is similar to changing it to read-only. Currently, various systems have different application capacities.

POSIX 1003.1e also proposes a capability definition, usually known as POSIX capability. The definition in Linux is not the same. The kernel uses these capabilities to Split root permissions because the root permissions in traditional * NIX systems are too powerful.

2.2.Linux uses POSIX capabilities to replace traditional trust-like models

Each process has three bitmap related to capabilities: inheritable (I), permitted (P), and inductive (E), corresponding to the process descriptor task_struct (include/linux/sched. h) cap_effective, cap_inheritable, and cap_permitted. Each capability is represented by one digit. 1 indicates a certain capability, and 0 indicates no. When a process requires a special operation, the operating system checks whether the corresponding bit of cap_valid tive is valid, instead of checking whether the valid UID of the process is 0. For example, if a process needs to set the system clock, the Linux kernel will check whether CAP_SYS_TIME bit (25th bits) of cap_effective is valid,

Cap_permitted indicates the capabilities that a process can use. Cap_permitted can contain capabilities not available in cap_permitted. These capabilities are temporarily abandoned by the process itself. It can also be said that cap_permitted is a subset of cap_permitted. It is helpful to improve security if the process does not have the necessary capabilities to give up. For example, ping only requires CAP_NET_RAW. If it does not provide other capabilities, it will not cause too much damage to the system even if it has security defects. Cap_inheritable indicates the ability to be inherited by programs executed by the current process.

3. Linux support capabilities

Linux implements seven POSIX 1003.1e specifications and 21 (as of version 2.4.7-10) Linux kernels, these capabilities are available in/usr/src/linux/include/linux/capability. h file. The details are as follows:

Capability name numeric description
CAP_CHOWN 0 allows change of File Ownership
CAP_DAC_OVERRIDE 1 ignores all DAC access restrictions on files
CAP_DAC_READ_SEARCH 2 ignores all restrictions on read and search operations
CAP_FOWNER 3 if the file belongs to the UID of the process, the file restriction is canceled.
CAP_FSETID 4 allows setuid bit
CAP_KILL 5 allows sending signals to processes that do not belong to itself
CAP_SETGID 6 allow group ID change
CAP_SETUID 7 allows you to change the user ID
CAP_SETPCAP 8 allows the ability to transfer to other processes and to delete any other processes.
CAP_LINUX_IMMUTABLE 9 allows you to modify IMMUTABLE and APPEND-ONLY attributes of a file.
CAP_NET_BIND_SERVICE 10 can be bound to a port smaller than 1024.
CAP_NET_BROADCAST 11 allows network broadcast and multicast access
CAP_NET_ADMIN 12 allows you to perform network management tasks: interfaces, firewalls, and routes. For more information, see/usr/src/linux/include/linux/capability. h.
CAP_NET_RAW 13 allows the use of raw sockets
CAP_IPC_LOCK 14 allows locking shared memory segments
CAP_IPC_OWNER 15 ignore the IPC ownership check
CAP_SYS_MODULE 16 insert and delete Kernel Modules
CAP_SYS_RAWIO 17 allows access to ioperm/iopl
CAP_SYS_CHROOT 18 can be called using the chroot () System
CAP_SYS_PTRACE 19 allows tracking of any process
CAP_SYS_PACCT 20 allows you to configure process accounting)
CAP_SYS_ADMIN 21 allows you to perform system management tasks, such as loading/detaching file systems, setting disk quotas, and enabling/disabling swap devices and files. For details, see the/usr/src/linux/include/linux/capability. h file.
CAP_SYS_BOOT 22 allows you to restart the system.
CAP_SYS_NICE 23 allows you to increase the priority of other processes.
CAP_SYS_RESOURCE 24 ignores resource restrictions
CAP_SYS_TIME 25 allows you to change the system clock.
CAP_SYS_TTY_CONFIG 26 allow TTY device configuration
CAP_MKNOD 27 allows mknod () system calls
CAP_LEASE 28 Allow taking of leases on files

4. Capability Boundary set

The Linux2.2 Kernel provides basic support for capabilities. However, some difficulties have been encountered after the introduction of capabilities. Although the kernel of Version 2.2 is understandable, it lacks an interface between the system and the user. In addition, there are some other problems. This situation has been greatly improved since version 2.2.11, and the concept of capability bounding set has been introduced in this version, solved the interface problem between the system and the user. Capability bounding set is the capability that all processes in the system can retain. If a certain capability does not exist in the capability Boundary set, all processes in the system do not have this capability, even if they are executed with super user permissions.

The capability Boundary set is exported using the sysctl command. You can view the system's reserved capabilities in/proc/sys/kernel/cap-bound. By default, all bits in the capability Boundary set are enabled.

Root users can write new values to the capability Boundary set to modify the system's reserved capabilities. However, it should be noted that the root user can delete from the capability boundary, but cannot restore the ability to be deleted. Only the init process can add capabilities. Generally, if a capability is deleted from the capability boundary, it can be restored only after the system is restarted.

Deleting unnecessary capabilities in the system is very beneficial to improve system security. If you have an important server, you are worried about the security of the kernel module that can be loaded. And you do not want to completely prohibit the use of kernel modules in the system or some device drivers are some kernel modules. In this case, it is best to enable the system to load all modules at startup, and then disable loading/detaching any kernel modules. In Linux, the capacity of the kernel module is controlled by CAP_SYS_MODULE. If the CAP_SYS_MODULE is deleted from the capacity boundary, the system will no longer allow loading/detaching any kernel module.

The value of CAP_SYS_MODULE is 16, so we can use the following command to delete it from the capability boundary:

Echo 0 xFFFEFFFF>/proc/sys/kernel/cap-bound

5. lcap

Although we can directly modify/proc/sys/kernel/cap-bound to delete a certain capability of the system, this is inconvenient after all. There is a program lcap that helps us easily Delete the specified capabilities from the system. It can beHttp://home.netcom.com /~ Spoon/lcap/Download. It can be used directly after compilation. Without parameters, lcap can list the capabilities currently supported by the system:

[Root @ nixe0n lcap-0.0.6] #./lcap
Current capabilities: 0 xFFFFFEFF
0) * CAP_CHOWN 1) * CAP_DAC_OVERRIDE
2) * CAP_DAC_READ_SEARCH & nbs