Bugzilla – Bug 1225317
AUDIT-WHITELIST: systemd: Please review the new DBUS /polkit stuff brought by v256
Last modified: 2024-07-17 07:38:03 UTC
Hello, The next major version of system (v256) will come with a host of new features and thus a bunch of methods/actions to review. Could you please review them ? I created the following project that will be used as the devel project for v256: https://build.opensuse.org/package/live_build_log/home:fbui:systemd:v256/systemd/openSUSE_Factory/x86_64 You should find the build logs there where the list of methods/actions to review is detailed. Please note that the integration is still WIP hence most of the new stuff has been temporarily packaged in the systemd-experimental subpackage. But some of them will be moved in different subpackages once the integration will be finished. Thanks in advance.
Created attachment 875124 [details] OBS build logs for v256 For convenience, I attached the build logs.
Thanks for the bug report. We will schedule it in our team shortly.
I went through the new D-Bus and Varlink methods, their respective authorization policies, the Polkit check implementations, and had a *cursory* look at the actual method implementations. D-Bus methods: - org.freedesktop.import1.cancel - Implemented in: src/import/importd.c - org.freedesktop.home1.activate-home - Implemented in: src/home/homed-home-bus.c - Explained in commit 336b1f1936ffbc62fa2cb189d8f86fbd982dcf15 Varlink [1] methods: - io.systemd.credentials.encrypt io.systemd.credentials.decrypt - Implemented in: src/creds/creds.c - io.systemd.mount-file-system.mount-image io.systemd.mount-file-system.mount-image-privately io.systemd.mount-file-system.mount-untrusted-image io.systemd.mount-file-system.mount-untrusted-image-privately - Implemented in: src/mountfsd/mountwork.c - org.freedesktop.network1.set-persistent-storage - Implemented in: src/network/networkd-manager-varlink.c - Specifies whether persistent storage for systemd-networkd is available Regarding the image mounting functions, the terminology was a bit unclear to me at first. Trusted vs untrusted refers to the location of the image, i.e. there's a set of trusted directories, defined in `src/shared/discover-image.c`. Likewise, the presence/absence of the "-privately" suffix refers to the namespace the image is mounted in. "mount-*image" mounts into the host ns and "mount-*image-privately" mounts into a private user ns. The latter functions have a more relaxed authorization policy. All in all I see no obvious problem with any of this and we can whitelist it. [1] https://lwn.net/Articles/742675/
The whitelisting is done. Let us know when you submit the systemd changes to Factory, so that we submit the whitelistings together.
Thanks for tackling this quickly. I'll let you know when I'll submit v256 although this probably won't happen within the 2 next weeks.
(In reply to Franck Bui from comment #6) > Thanks for tackling this quickly. > > I'll let you know when I'll submit v256 although this probably won't happen > within the 2 next weeks. Good point, yes, please let us know. The D-Bus whitelisting will have to enter Factory simultaneously with systemd v256. The Polkit whitelisting can move forward already, because it only adds new policies and doesn't remove or change existing ones.
I reverted the D-Bus whitelisting for now because it's in the way of other whitelistings. Please ping us in this bug when you're ready for the submission. (No hurry).
Hi Wolfgang, It took more time than expected (as usual...) but v256 has been just submitted via sr#1187947.
(In reply to Franck Bui from comment #9) > Hi Wolfgang, > > It took more time than expected (as usual...) but v256 has been just > submitted via sr#1187947. Thanks for the heads up! In the meantime, I noticed that our D-Bus whitelist mechanism allows multiple hashes, so currently both the old and new methods are whitelisted and rpmlint should not give you any problems.