DEV Community: olaboyejo

Linux Capabilities Use Cases - systemd

olaboyejo — Tue, 17 Aug 2021 11:22:16 +0000

Introduction

The last post was a discussion on capabilities sets and the bits that make up the sets. We also saw how we can examine the capabilities sets of threads and processes. In this post, we will be looking at the application of capabilities to processes managed by systemd.

systemd

systemd is the default system and services manager on most modern Linux distributions. When run as the first process on boot (PID 1), It manages the startup, operation of userspace services. As the init system, the systemd process runs with an effective User ID of 0.

(base) boye@hp7940m1:~$ ps -fp 1
UID          PID    PPID  C STIME TTY          TIME CMD
root           1       0  0 Aug16 ?        00:00:41 /sbin/init splash
(base) boye@hp7940m1:~$

To explore the capabilities sets of the processes managed by systemd and the configuration settings that change the default behaviour, we will be using a small python script for convenience. This script (cap_display) is on github. This repository has some of the other files we will be using for demonstration. The README.md file has the descriptions and installation instructions for these files.

The cap_display script scrapes the /usr/include/linux/capability.h file to create a mapping between capability names and their bit values. It also reads the hexadecimal representation of the capabilities set for a PID in /proc/PID/status file and uses the mapping to print a human-friendly representation of the capabilities set.

(capabilities_show) (base) boye@hp7940m1:~/Documents/dev/capabilities_show$ cap_display --pid 1
Name:   systemd
Tgid:   1
Pid:    1
PPid:   0
Uid:    0       0       0       0
Gid:    0       0       0       0

CapInh:  0000000000000000        None
CapPrm:  0000003fffffffff        cap_audit_read,cap_block_suspend,cap_wake_alarm,cap_syslog,cap_mac_admin,cap_mac_override,cap_setfcap,cap_audit_control,cap_audit_write,cap_lease,cap_mknod,cap_sys_tty_config,cap_sys_time,cap_sys_resource,cap_sys_nice,cap_sys_boot,cap_sys_admin,cap_sys_pacct,cap_sys_ptrace,cap_sys_chroot,cap_sys_rawio,cap_sys_module,cap_ipc_owner,cap_ipc_lock,cap_net_raw,cap_net_admin,cap_net_broadcast,cap_net_bind_service,cap_linux_immutable,cap_setpcap,cap_setuid,cap_setgid,cap_kill,cap_fsetid,cap_fowner,cap_dac_read_search,cap_dac_override,cap_chown
CapEff:  0000003fffffffff        cap_audit_read,cap_block_suspend,cap_wake_alarm,cap_syslog,cap_mac_admin,cap_mac_override,cap_setfcap,cap_audit_control,cap_audit_write,cap_lease,cap_mknod,cap_sys_tty_config,cap_sys_time,cap_sys_resource,cap_sys_nice,cap_sys_boot,cap_sys_admin,cap_sys_pacct,cap_sys_ptrace,cap_sys_chroot,cap_sys_rawio,cap_sys_module,cap_ipc_owner,cap_ipc_lock,cap_net_raw,cap_net_admin,cap_net_broadcast,cap_net_bind_service,cap_linux_immutable,cap_setpcap,cap_setuid,cap_setgid,cap_kill,cap_fsetid,cap_fowner,cap_dac_read_search,cap_dac_override,cap_chown
CapBnd:  0000003fffffffff        cap_audit_read,cap_block_suspend,cap_wake_alarm,cap_syslog,cap_mac_admin,cap_mac_override,cap_setfcap,cap_audit_control,cap_audit_write,cap_lease,cap_mknod,cap_sys_tty_config,cap_sys_time,cap_sys_resource,cap_sys_nice,cap_sys_boot,cap_sys_admin,cap_sys_pacct,cap_sys_ptrace,cap_sys_chroot,cap_sys_rawio,cap_sys_module,cap_ipc_owner,cap_ipc_lock,cap_net_raw,cap_net_admin,cap_net_broadcast,cap_net_bind_service,cap_linux_immutable,cap_setpcap,cap_setuid,cap_setgid,cap_kill,cap_fsetid,cap_fowner,cap_dac_read_search,cap_dac_override,cap_chown
CapAmb:  0000000000000000        None
(capabilities_show) (base) boye@hp7940m1:~/Documents/dev/capabilities_show$

Above is an examination of PID 1 using the script. Here we can see the UID and GID =0 and the effective, permitted and bounded capabilities sets for the process. The have all their bits set. This is expected for a process with the EUID=0.

We will be looking at three configuration options in systemd unit files that can influence the capabilities set for services managed by systemd. These are the User, AmbientCapabilities and CapabilityBoundingSet options.

Default behaviour for processes managed by systemd

We will be exploring the behaviour of processes managed by systemd from the perspective of a dummy service unit that tells the current time. This service is a go application (DayTimeServer) which you can find in the post series repository. The code is adapted from one of the examples in this book.

We run our cutting edge service by running the executable and specifying a TCP port number as shown below;

(base) boye@hp7940m1:~/go/bin$ ./DayTimeServer 1021
Fatal Error: listen tcp :1021: bind: permission denied
(base) boye@hp7940m1:~/go/bin$

No surprises at the failure above because an unprivileged user cannot use the port numbers under 1024. The service is started below with TCP port 1029.

(base) boye@hp7940m1:~/go/bin$ ./DayTimeServer 1029

(base) boye@hp7940m1:~/go/bin$ nc localhost 1029
2021-08-17 21:29:47.570860654 +1200 NZST m=+50.203298522
(base) boye@hp7940m1:~/go/bin$

We get the date and time using the nc utility to probe the server.

Unprivileged Port

We now run the server as a systemd managed service using the unit file configuration below.

(base) boye@hp7940m1:/etc/systemd/system$ cat daytimeServer.service 
Description=Cutting Edge DayTime Announcement Service

[Service]
Type=simple
ExecStart=/home/boye/go/bin/DayTimeServer 3000

[Install]
WantedBy=multi-user.target

We can see the process is running on TCP port 3000.

The capabilities set, just like that of systemd, has all the effective capability set bits enabled.

Privileged Port

We will now attempt to run same service with a same privileged port 1021

(base) boye@hp7940m1:/etc/systemd/system$ cat daytimeServer.service 
Description=Cutting Edge DayTime Announcement Service

[Service]
Type=simple
ExecStart=/home/boye/go/bin/DayTimeServer 1021

[Install]
WantedBy=multi-user.target

We can see that it runs successfully and an examination of the process ID shows that it has all the effective capabilities bits set.

In summary, the processes managed by systemd run with all the privileges enabled by default.

systemd unit file with User option

We will now run the same binary service but we will be setting the user to a non-privileged user. Below is the systemd service unit file.

(base) boye@hp7940m1:/etc/systemd/system$ cat daytimeServer_user.service 
Description=Cutting Edge DayTime Announcement Service

[Service]
Type=simple
ExecStart=/home/boye/go/bin/DayTimeServer 3001
User=boye

[Install]
WantedBy=multi-user.target

We can see from the output above that the process has no effective capability bits set.

systemd unit file with AmbientCapabilities option

Now the boss just informed us that our biggest competitor in the daytime service app business just raised the bar. They allow their service to be run on privileged ports. Using the Ambient capabilities option in the service unit file, we can add this feature to our service.

(base) boye@hp7940m1:/etc/systemd/system$ cat daytimeServer_user_net_bind.service 
Description=Cutting Edge DayTime Announcement Service

[Service]
Type=simple
ExecStart=/home/boye/go/bin/DayTimeServer 105
User=boye
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

In the unit file above, we are attempting to run the service on TCP port 105 and we are setting the CAP_NET_BIND_SERVICE bit in the ambient capabilities set. That capability empowers an unprivileged user to bind to network ports below 1024.

We can see from the output above that even though the process is owned by a regular user, using the AmbientCapabilities option allows the process to bind to a privileged port number. The cap_display output for the process ID shows that the cap_net_bind_service bit in the effective capabilities set has been enabled.

The ambient capabilities set is used to transfer privileges from the parent process (systemd, PID 1) to the service process.

systemd unit file with CapabilityBoundingSet option

The final option we will be exploring in this post is particularly useful for situations where we don't want to change the user for the process but we want the process to be limited to just the required privileges. The CapabilityBoundingSet option in the service unit file serves as a limiting set of what can be transferred from the parent to the child process.

We will look at the effects by using the service unit file below which effectively disables all the bits in the bounding capabilities set.

(base) boye@hp7940m1:/etc/systemd/system$ cat daytimeServer_limited.service 
Description=Cutting Edge DayTime Announcement Service

[Service]
Type=simple
ExecStart=/home/boye/go/bin/DayTimeServer 3002
CapabilityBoundingSet=

[Install]
WantedBy=multi-user.target

From the cap_display output we can see that in spite of the process running as a privileged user, it has no effective permissions set. Attempting to use a privileged port will meet with failure as shown below.

(base) boye@hp7940m1:/etc/systemd/system$ cat daytimeServer_limited_privilege_port_attempt.service 
Description=Cutting Edge DayTime Announcement Service

[Service]
Type=simple
ExecStart=/home/boye/go/bin/DayTimeServer 108
CapabilityBoundingSet=

[Install]
WantedBy=multi-user.target

We have just seen three options to modify the default behaviour that confers all privileges to all processes started and managed by systemd. The CapabilityBoundingSet option in the unit files can be used to decrease the capabilities that can be passed to a child process running as root and the AmbientCapabilities option is useful for giving specific privilege(s) to child processes that belongs to an unprivileged user.

The next post will explore the docker use case.

Linux Capabilities Set and Bits

olaboyejo — Sun, 15 Aug 2021 08:02:54 +0000

Introduction

In the previous post, the concept of Linux capabilities was introduced. In this post, I will be exploring the capability sets and capability bits in a bit more detail. This is a prelude to future posts that will examine the practical use cases of capabilities in systemd, dockerd and fork/execve.

Capabilities Sets

Capabilities are properties of threads (or processes). They have thread-level granularity. Applications also have a concept of capabilities and this will be explored separately in more depth when we investigate the execve use cases. A thread has the following capability sets;

Effective Capability Set

This is the set of privileged activities that the kernel performs permission checks on before a thread can accomplish a task.

Inheritable Capability Set

The capabilities in this set are transferable between parent and child processes after an execve system call for privileged programs. This will be discussed in more detail in a future post dealing with fork/clone and execve system calls

Permitted Capability Set

The permitted set serves as a limiting superset for the effective set. The capabilities that are not set in the permitted set cannot be enabled in the effective set except;

The the program file capability set contains the capability in its permitted set.
The program it (the thread) is executing is with the set-user-ID-root.

It also limits the capabilities that can be inherited if the CAP_SETPCAP capability is not present in a thread's effective capability set.

Ambient Capability Set

This capability set is useful when a non privileged thread needs its privileges preserved during an execve system call. The ambient capability set allows the transfer of capabilities during the execve systems call. They are preserved across a process that is unprivileged.

Bounded Capability Set

This capability set is a limiting superset for capabilities that can be added to the inheritable during an execve syscall. It is also a limiting factor for permitted set because its AND'ed to the permitted set during execve.

Thread/Process Capability Sets

The capability sets attached to a thread or a process can be read from the /proc/pid/status file where pid is process or task ID. For example to see the capabilities the current process is using, we can run the command below;

cat /proc/$$/status

The $$ is a special bash parameter representing the current process so the command below will print the current process ID.

echo $$

The file /proc/pid/status contains a lot more information about the process ID under observation. The screen-dump below is a grep of just the capabilities section of the output of my current shell process.

boye@hp7940m1:~/Documents/dev/capabilities_show$ echo $$
13575
boye@hp7940m1:~/Documents/dev/capabilities_show$ grep Cap /proc/13575/status
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
boye@hp7940m1:~/Documents/dev/capabilities_show$

The capabilities sets introduced earlier can be seen in the output above. They are in hexadecimal form with each character representing a nibble(four bits). The individual capabilities are bit positions in the 64 bit output for each capability set. Setting the bit(1) in the position enables the respective capability, while clearing it (0), disables the capability for the capability set.

The arrangement of the capabilities in the 64 bit data structure is defined in the header file /usr/include/linux/capability.h. The content of this file is determined by the kernel version so you will find that different kernel versions can have varying levels of support for capabilities. The bit positions are numbered from 0 to the latest supported by the kernel. To check the latest capability supported on a system;

cat /proc/sys/kernel/cap_last_cap

The output from my system is shown below. It does not have the CAP_BPF and CAP_PERFMON capabilities introduced in Kernel version 5.8.

boye@hp7940m1:~/Documents/dev/capabilities_show$ uname -a
Linux hp7940m1 5.4.0-80-generic #90-Ubuntu SMP Fri Jul 9 22:49:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
boye@hp7940m1:~/Documents/dev/capabilities_show$ cat /proc/sys/kernel/cap_last_cap 
37
boye@hp7940m1:~/Documents/dev/capabilities_show$

The cap_last_cap file output of 37 means that the kernel has support for positions 0 - 37 which means that 38 capabilities are supported. This can be seen in the capability bounding set for the current shell process.

CapBnd: 0000003fffffffff

An examination of the values shown there are nine f(1111 in binary) characters and one 3(11 in binary) character. That gives 36(9X4) + 2 ones which means there are 38 bit positions set which is all the capabilities supported on the system.

To see a human readable translation of the hexadecimal representation, you can use the capsh utility.

boye@hp7940m1:~/Documents/dev/capabilities_show$ capsh --decode=0x0000003fffffffff
0x0000003fffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
boye@hp7940m1:~/Documents/dev/capabilities_show$

The output above shows the capabilities enabled in the capability bounding set for the current shell process.

With the foregoing, we have enough background to see the practical applications of capabilities. We will start that examination with systemd in the next post.

Linux Capabilities Overview

olaboyejo — Thu, 12 Aug 2021 10:56:34 +0000

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.