Zbigniew Jędrzejewski-Szmek
9eee40e687
This PR changes some SELinux bits related to working with alternate roots (specifically when using `--root` or `--image` on a bunch of executables). It addresses bug #42643 and it's hopefully the more whole approach than the naive approach I PR'ed in #42644. Before this PR the 'wrong' labels get applied because the path lookups in the SELinux label database are prefixed with whatever the location of the alternate root is (explained in more detail below). Initially I had taken a very naive approach that did fix the issue by stripping the alternate root from the path; however this still looks up that path in the hosts' label database, which might differ from the one contained in the alternate root. So this expanded approach actually reads the label database from the alternate root, strips the prefix *if* an alternate root is used directly in `selinux-util.c` and then uses that to assign labels instead. See under the line for the behavior pre/post. I've tried builds of this PR on both enforcing/non-enforcing/non-enabled hosts *and* on enabled/non-enabled disk images and things seem to work or at least fall back to ignoring MAC when required bits aren't present. One thing is *if* an `/etc/selinux/config` is present that defines a `SELINUXTYPE=` we *do* require the policy given to be present in the image. This is the only new actual error in this code path that doesn't get ignored. We *could* verify that the path exists and also ignore it but I personally don't think that's the right approach since the actual system itself would likely also be broken anyhow. Let me know thoughts on that. There's a tight coupling here still with the *hosts* SELinux policy in that to set (potentially) unknown labels to the policy loaded in the host kernel these executables would need to execute in a domain that allows transitioning to `mac_admin`. I'd say that `install_t` is the most likely candidate for that. See the first comment on this PR for more explanation on it/request for input. --- When mounting `a.raw` before running any tooling against it and showing the `/etc/shadow` file labels we have: ``` € sudo systemd-dissect --mount test/a.raw test/mnt/a € ls -Zlart test/mnt/a/etc/shadow ----------. 1 root root system_u:object_r:shadow_t:s0 520 Jun 27 07:55 test/mnt/a/etc/shadow € sudo systemd-dissect ---umount test/mnt/a ``` After running `systemd-firstboot` against the image, then remounting, note the labels that have been changed to incorrect values: ``` € sudo systemd-firstboot --image test/a.raw --root-password test /home/user/src/github.com/teamsbc/artifacts/test/a.raw: /etc/passwd written. /home/user/src/github.com/teamsbc/artifacts/test/a.raw: /etc/shadow written. € sudo systemd-dissect --mount test/a.raw test/mnt/a € ls -Zlart test/mnt/a/etc/shadow ----------. 1 root root system_u:object_r:init_var_run_t:s0 579 Jun 27 08:01 test/mnt/a/etc/shadow ``` The behavior before this PR looks up the labels in the label database of the host, but the path that gets looked up is the path where the image is temporarily mounted, or in the case of `--root` where the root is on the host. Since that path doesn't define any labels we get the labels of the location where the file was created on the host. In this case since `--image` was used, which mounted things in a temporary location we end up with `var_run_t`. If this image is booted things that want to read `/etc/shadow` might not be allowed to read files labeled this way; thus services fail to start, and root can't login when SELinux is in enforcing mode. After this PR is applied there are two main differences in how things are handled. The first being that instead of reading the label database from the host (which might have none, or have a different one from the one contained inside an image or root) we read the label database from inside the alternate root. This tries to make sure we get the correct labels for given paths. Second, and most importantly, if we did init SELinux with an alternate root then any paths passed to the relevant label lookup functions strip that alternate root from the path. While previously we'd look up a path like `/run/dissect-XXXX/etc/shadow` we now look up a path like `/etc/shadow` *and* this path gets looked up in the label database in the alternate root. Together these things give in my opinion better handling of SELinux in alternate roots. To confirm things work here's the same operations on the second copy of our image: ``` € sudo systemd-dissect --mount test/b.raw test/mnt/b artifacts € ls -Zlart test/mnt/b/etc/shadow ----------. 1 root root system_u:object_r:shadow_t:s0 520 Jun 27 07:55 test/mnt/b/etc/shadow € sudo ~/src/github.com/systemd/systemd/build/systemd-firstboot --image test/b.raw --root-password test /home/user/src/github.com/teamsbc/artifacts/test/b.raw: /etc/passwd written. /home/user/src/github.com/teamsbc/artifacts/test/b.raw: /etc/shadow written. € sudo systemd-dissect --mount test/b.raw test/mnt/b € ls -Zlart test/mnt/b/etc/shadow ----------. 1 root root system_u:object_r:shadow_t:s0 579 Jun 27 08:44 test/mnt/b/etc/shadow ``` Showing that we now have the correct labels applied.
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