Christian Brauner
43914520c1
Execution from an overlayfs mount is currently denied even when every layer sits on a signed dm-verity device. The hooks compare file->f_inode->i_sb->s_dev against the map of trusted devices and for a file on an overlay that's the overlay's own anonymous device, never the backing block device. Kernel v7.2 grew the bpf_real_data_inode() kfunc which resolves a file to the inode hosting its data. Use it from bprm_check_security and mmap_file which both get to see the union-level file. They become lsm.s/ programs because the kfunc is sleepable. That doesn't raise our kernel requirements, both have been in sleepable_lsm_hooks since v5.11. The file_mprotect hook stays non-sleepable. It runs under mmap_write_lock where sleeping in d_real() would invert the documented i_rwsem -> mmap_lock order, and it doesn't need the kfunc anyway. By the time a vma exists ovl_mmap() has already installed the backing file into vma->vm_file. The initramfs trust window keeps comparing the mount device. If the initrd is itself a union mount then userspace only ever recorded the union's anonymous s_dev. The verity map is keyed by block device so that one gets compared against the resolved device. The kfunc is declared __weak __ksym and every call is gated on a const volatile .rodata flag that PID1 only sets when the kernel provides it. So the object still loads on pre-7.2 kernels where files on union filesystems are denied as before. The flag stays off until the loader learns to set it in a followup. The file argument of bpf_lsm_mmap_file() is annotated __nullable since v7.0 so the verifier won't let us hand it to the kfunc unless we branch on it first. Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
System and Service Manager
Details
Most documentation is available on systemd's website.
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