KDE6 release: D-Bus and Polkit Galore (SUSE security team blog)
The SUSE security team restricts the installation of system wide D-Bus services and Polkit policies in openSUSE distributions and derived SUSE products. Any package that ships these features needs to be reviewed by us first, before it can be added to production repositories.In November, openSUSE KDE packagers approached us with a long list of KDE components for an upcoming KDE6 major release. The packages needed adjusted D-Bus and Polkit whitelistings due to renamed interfaces or other breaking changes. Looking into this many components at once was a unique experience that also led to new insights, which will be discussed in this article.
Posted Apr 3, 2024 17:19 UTC (Wed)
by Duncan (guest, #6647)
[Link]
As a Gentooer I can of course toggle features such as polkit at build time via USE flags. Given that I never wanted to take the time to understand polkit's configuration to the point I could be fully comfortable using it in its designated security context, USE=-policykit and no polkit on my system! Which is for the most part just fine since most polkit usage is GUI authentication and I have a policy of no root gui, all system level operations are done at the CLI (or TUI such as mc and htop), meaning I have little use for polkit.
Also, CLI login and run a plasma-wayland session from there, no *DDM graphical login installed. (And a lot of other "bloat" like semantic-desktop and pipewire USE-disabled and not installed, as well. )
But the kauth/kwalletmanager polkit integration and "fake security" described in TFA is "interesting" in the context of a non-existent polkit. IIRC it was the early kde5 era when I decided I needed some kwallet config changes, only to discover that without polkit the kwalletmanager GUI was effectively read-only -- despite the settings being user-level not system-level!
Turned out that kwallet stored its settings in an unencrypted text rcfile (kwalletrc IIRC), owned by my normal user/group, but I couldn't GUI-edit the settings despite seeing them there, and had to text-edit the rcfile instead. Of course that meant some digging around to figure out the exact significance of a number of the key=value ini-style lines, because some of them didn't quite correspond to the descriptions in the GUI.
But I distinctly remember how odd and frustrating it was to me, to have the GUI insist I wasn't authenticated to operate on a text-based config file owned by the same user/group that the app was running as and that it had originally written -- tho likely back in the kde3 (pre-polkit!) or kde4 era, presumably before it required that fake authentication to operate on something it owned in any case!
Seems the SUSE security team find it odd too, even when they /are/ running polkit!
One would /think/ such settings, if not considered appropriate for the user to edit without authentication, would have XDG-specified handling much like per-user tmpdir settings, maybe something in /etc/usersec/$user/ (or $UID?) that an as-root polkit-authenticated daemon could write to on behalf of the user, such that the file would be in a per-user dir but not /owned/ by the user. Either that or just let the user edit the settings in the GUI that they could edit in a texteditor anyway, since they own the file and have permissions to the path it's in.
KDE6 release: D-Bus and Polkit Galore (SUSE security team blog)