Christian Brauner
51e88de7f8
Add self-protection guard programs to the RestrictFileSystemAccess= skeleton that prevent non-PID1 processes from obtaining FDs to our maps, programs, or links via the bpf() syscall. This blocks the primary attack vector against the RestrictFileSystemAccess= policy: using BPF_MAP_GET_FD_BY_ID to get an FD to the verity_devices map, then BPF_MAP_UPDATE_ELEM to inject fake trusted devices. Protection of program and link IDs is defense-in-depth (the kernel already blocks BPF_LINK_UPDATE and BPF_LINK_DETACH for LSM tracing links). Additionally, a ptrace guard (lsm/ptrace_access_check) blocks PTRACE_MODE_ATTACH to PID1 from other processes, preventing extraction of sensitive state from PID1's address space via ptrace, /proc/1/mem, process_vm_readv(), or pidfd_getfd(). Guard logic: 1. Allow all BPF ops from PID1 (tgid == 1, unspoofable) 2. Deny BPF_MAP_GET_FD_BY_ID for our protected map IDs 3. Deny BPF_PROG_GET_FD_BY_ID for our program IDs 4. Deny BPF_LINK_GET_FD_BY_ID for our link IDs 5. Allow everything else (zero collateral damage) The guard starts inactive (all protected IDs default to 0 in .bss). After skeleton attach, PID1 queries kernel-assigned IDs via bpf_obj_get_info_by_fd() and writes them into the guard globals via the mmap'd .bss, then extracts owned FDs and destroys the skeleton. Destroying the skeleton unmaps the .bss page from PID1's address space, so no BPF state — guard globals, protected map/prog/link IDs, initramfs_s_dev — remains readable via /proc/1/mem. The kernel map data persists (held by the dup'd FDs) but is only accessible via bpf_map_* syscalls, which the guard itself blocks for non-PID1. 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