Functions allow some important system privileges to be evaluated in a separate thread, distinct from the current process. That way, you don’t have to run a program as root for it to access certain parts of the system.
As a solution resulting from the needs, Section 25 of POSIX.1e addresses this problem. The development of the privileges defined in this section and more has been completed with the release of Linux kernel version 2.6.26. Here’s everything you need to know about the capabilities in the Linux kernel.
Understanding the Capabilities API logic
Authorization control in Unix-based systems consists of two steps:
- If the current owner (Effective User ID, EUID) of the running application is null, the system does not check for authorization
- If the EUID value is non-zero, the system performs the control process according to the permissions of the effective user and group of the application in question
Some applications require more privileges (SUID, SGIT bits) while running. The most typical example is the passwd application. This allows users of a system to change their passwords. However, to write to the /etc/shadow File in which the encrypted passwords are kept must be worked with root user rights (ie userid = 0).
To solve this problem, the passwd application has a SUID bit. Regardless of which user runs this application, the active owner (EUID) is always root:
ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 32552 Jul 23 2021 /usr/bin/passwd
Being able to run SUID applications in the traditional Unix authentication model seems to have solved the problem. However, critical bugs in applications with SUID bits open the door to executing unwanted code for users with full privileges in the system. An ideal application should be able to run without root user privileges whenever possible.
The problem doesn’t just end with the SUID bit. You must also have root user privileges if you want to listen on a privileged TCP or UDP port less than 1024 on Unix-based systems. For example, to listen on a web server’s TCP 80 port, you must run the application as the root user.
Over the years it has become clear how devastating it is to run software that provides services to the network environment with a fully authorized user account. As an interim solution, it was assumed that only a specific and smaller part of the program listens as root on the privileged port and then changes the active userid for subsequent processes to another user (e.g. the user none with restricted rights). .
This system, which has been used for years, has proven itself through its simplicity and is still being used efficiently. However, nowadays it is possible to get some additional skills that are application specific via the Linux Skills API without requiring root privileges, apart from the system mentioned above.
The Linux capability model, explained!
The most comprehensive implementation of the Capabilities API can be found in the Linux kernel. Modern Linux distributions also try to use this new model system-wide as much as possible.
For example, for the ping application to work, it must be able to open RAW sockets, which are generally reserved for root users only. The problem with old Linux distributions is to give the application the SUID bit so that normal users can use it. In these versions, if you remove the SUID bit from the application and try to run the application as a normal user, you will get the following error message:
ping: icmp open socket: Operation not permitted
While on modern Linux distributions, the ping application probably doesn’t have a SUID bit:
ls -l /bin/ping
-rwxr-xr-x. 1 root root 95232 Jul 25 2021 /bin/ping
Despite this, you can successfully run the application as a normal user. The mechanism that makes this possible is that the ping application has the special ability CAP_NET_RAW.
You can learn the additional features of the application with getcap command as follows:
sudo getcap /bin/ping
If the getcap command returns an empty response, you can set this value manually with:
sudo setcap cap_net_raw+ep /bin/ping
The process capability model
In the Linux implementation, the capabilities of each process are grouped under three headings:
|permitted||In this cluster there is a list of allowed additional capabilities for the relevant process. Granting permission does not mean it can be actively used at that time. Here you have the option of including the permissions with an additional action in the effective capability set.|
|Effective||It shows the currently active capability list of the related process. With the utility functions that regulate the skill system, it is possible to relinquish or regain a skill. In any case, this is only possible among the already authorized persons of the approved group.|
|hereditary||When an application launches a new process, the newly launched process displays the list of capabilities it will inherit from the allow list.|
The list of allowed, effective, and inheritable abilities for running processes is displayed as a bitmask on the lines at all times CapPrm, CapEffand CapInh in the file /proc/
For example, try reading the values of your running shell application from the /proc/self/status File:
cat /proc/self/status | grep Cap
The file capability model in Linux
The operation of the file capability system depends on the premise that these properties can be stored in the virtual file system (VFS) layer. Similar to the process model, the capabilities for files fall under three headings:
The system determines the allowable capabilities of the process when the corresponding executable is running in that cluster.
In contrast to the process capability model, this header stores only one bit: active or inactive. If the bit is active, the capabilities defined in the file’s allowed list are automatically included in the effective capability list of the respective process when this file is executed and a process is created. If the bit is not active, the automatic transfer of the allowed capabilities on the file to the running process is not performed.
However, if the application’s code is integrated with the capability system, it can enable the permissions in the allowed set of the file with system calls. The main purpose of this behavior is to ensure that legacy applications that do not contain Capability System-specific code, development can work with the Capability System at the software code level without requiring any source code changes.
You might think that better written applications use features only when they are needed. When the bit is active, all capabilities on the allow list become active when the application starts.
As in the process model, the corresponding file runs and a process takes place. After that, if another application is running within the process, it will be added to the new process’s allow list. In summary, it displays a list of skills to inherit.
The Role of Skills in a Linux System
If you run a specific process as a normal user, you have no privileges. This allows you to access only the partitions that the system allows for regular users. The main reason for this is to increase system security and implement such measures.
Allowing all users access to all resources can lead to a serious security vulnerability. It will be very easy for people using the system for malicious purposes to exploit system vulnerabilities. Linux skills come in handy in such matters. You can easily strengthen the security of your applications with the kernel-supported Capabilities API.
Linux skills are just one of the issues to think about in order to implement very powerful methods like splitting the root user’s privileges, assigning different privileges to unprivileged users, and taking various precautions about open ports in Internet services running Linux servers to perform.
This article was previously published on Source link