Christian Brauner
68fe7fa4d6
Add a new RestrictFileSystemAccess= boolean setting in the [Manager] section of system.conf that enforces execution only from signed dm-verity block devices and the initramfs during early boot. When RestrictFileSystemAccess=yes is set, PID1 loads a BPF LSM program early in boot that: Integrity tracking (self-populating, no userspace involvement): - bdev_setintegrity: records dm-verity signature status in a BPF hash map when the kernel signals device integrity via security_bdev_setintegrity() - bdev_free_security: removes devices from the map on teardown Execution enforcement (deny-default policy): - bprm_check_security: blocks execve() from untrusted sources - mmap_file: blocks PROT_EXEC mmap (shared libs, anonymous exec memory) - file_mprotect: blocks W->X transitions (JIT, libffi, etc.) Trust anchors: - Signed dm-verity volumes (sig_valid flag in the BPF map) - Initramfs (s_dev captured at load time, cleared after switch_root) - Everything else is denied (tmpfs, procfs, sysfs, anonymous PROT_EXEC) PID1 requires dm-verity require_signatures=1 to be enabled and refuses to load the BPF program otherwise, ensuring the kernel enforces that all dm-verity devices carry valid signatures. After attach, PID1 extracts owned FDs from the skeleton (link FDs + .bss map FD) and lets the skeleton be destroyed. The dup'd link FDs keep programs attached via the kernel reference chain (link FD -> bpf_link -> bpf_prog -> bpf_map). Destroying the skeleton unmaps the .bss page from PID1's address space so no BPF state is readable via /proc/1/mem. The .bss map FD is retained for targeted writes (clearing initramfs_s_dev after switch_root via mmap). Signed-off-by: Christian Brauner <brauner@kernel.org>
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release