SecureBits setting
The property SecureBits is a systemd unit setting used for sandboxing. It is available since systemd 1.
Purpose: change the behavior of Linux capabilities by setting the securebits flag of the prctl(2) syscall
New to securing and tuning systemd services? Start with the how to harden a systemd service unit article to learn tuning step-by-step, including the usage of relevant tools.
Why and when to use SecureBits
Systemd provides the unit setting SecureBits to define a few special bits that are related to Linux capabilities. These bits is a flag named securebits and used with the operations PR_SET_SECUREBITS and PR_GET_SECUREBITS as part of the syscall prctl(2). The purpose of these bits is to alter the special treatment of user ID 0 (root) when it comes to capabilities.
Mapping of the systemd values and Linux securebits
Keep capabilities
The Linux securebits flag SECBIT_KEEP_CAPS allows a thread to retain its permitted capabilities, named the permitted set. Normally it would lose its permitted capabilities right away when switching from zero to a nonzero user ID. When this flag is set, and the effective UID is already nonzero, and the process thread switches all other user IDs to nonzero, then the effective capabilities remain. Otherwise the effective capabilities would be cleared when switching.
This flag is not compatible with the SECBIT_NO_SETUID_FIXUP flag, as it is a so-called superset and includes the SETBIT_KEEP_CAPS.
Software may use older prctl(2) PR_SET_KEEPCAPS operation, which is the same as setting SECBIT_KEEP_CAPS.
The Linux kernel also has the securebits flag SECBIT_KEEP_CAPS_LOCKED. It makes SECBIT_KEEP_CAPS (keep-caps) immutable. So when this is set, no changes are allowed.
Related values for systemd SecureBits:
- keep-caps
- keep-caps-locked
Prevent setuid changes
The securebits flag SECBIT_NO_SETUID_FIXUP prevents changing the kernel process’s permitted, effective, and ambient capability when set. It applies to the situation where the effective user and filesystem user ID is switched between zero and a nonzero value.
To lock this functionality (set immutable flag), the kernel has a SECBIT_NO_SETUID_FIXUP_LOCKED flag, which equals to the systemd SecureBits value of no-setuid-fixup-locked.
Related values for systemd SecureBits:
- no-setuid-fixup
- no-setuid-fixup-locked
No root
With the securebits flag SECBIT_NOROOT set, the kernel will not grant capabilities to a program when the setuid is set or the real UID of zero uses the syscall execve(2).
This flag can be also be made immutable using the SECBIT_NOROOT_LOCKED flag.
Related values for systemd for SecureBits:
- noroot
- noroot-locked
Generic advice
Defining SecureBits and thereby changing the underlying securebits or prctl(2) flags definitely requires more knowledge of the software and service to be hardened.
Testing
With the systemd-run command we can test the individual values. To show the underlying securebits and their values, run capsh within the unit. Use a simple command like ps. Another interesting thing to test is what happens when sudo is involved.
# systemd-run --pty --property="SecureBits=noroot noroot-locked" capsh --print -- -c "sudo ps"
Running as unit: run-p9196-i9496.service
Press ^] three times within 1s to disconnect TTY.
Current: =
Bounding set =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,cap_perfmon,cap_bpf,cap_checkpoint_restore
Ambient set =
Current IAB:
Securebits: 03/0x3/2'b11 (no-new-privs=0)
secure-noroot: yes (locked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=
Guessed mode: UNCERTAIN (0)
sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted
sudo: unable to open /etc/sudoers: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
Values
Systemd unit setting SecureBits expects a string value.
Value | Intended action | Available since systemd version |
---|---|---|
keep-caps | Allows to keep capabilities (SECBIT_KEEP_CAPS) | 1 |
keep-caps-locked | If set, no changes to 'keep-caps' possible (SECBIT_KEEP_CAPS_LOCKED) | 1 |
no-setuid-fixup | Prevents changing the kernel process's permitted, effective, and ambient capability (SECBIT_NO_SETUID_FIXUP) | 1 |
no-setuid-fixup-locked | If set, no changes to 'no-setuid-fixup' possible (SECBIT_NO_SETUID_FIXUP) | 1 |
no-root | Don't grant capabilities to a program when set and user ID is zero (SECBIT_NOROOT) | 1 |
no-root-locked | If set, no changes to 'no-root' possible (SECBIT_NOROOT_LOCKED) | 1 |
Example to show the current value of SecureBits for the ssh service:
systemctl show --property=SecureBits ssh.serviceRelated hardening profiles
The systemd unit setting SecureBits is used in the following systemd hardening profiles. These hardening profiles help improving security of common Linux services and usually require minimal tuning.