Bug 1217191

I will work on this

The codebase for this is really small. It is mostly read-only: walking through
all pids in /proc and gather their inotify FD use counts. This information is
imperfect but that's okay for the purpose of the tool.

The only place where something privileged happens is when the system wide
inotify limits are changed. For this sysctl drop-in configuration files are
placed in /etc/sysctl.d. This part also looks sane.

I reviewed upstream commit 4d26650. We will keep this bug open and when the
KDE6 release is drawing near I will do a follow-up review of any changes
introduced till then.

So far I've only seen a Factory staging incident for KDE:Frameworks. This here
is for KDE:Applications. Do you also need the whitelisting for this here now
already?

(In reply to Matthias Gerstner from comment #3)
> So far I've only seen a Factory staging incident for KDE:Frameworks. This
> here
> is for KDE:Applications. Do you also need the whitelisting for this here now
> already?

I'd say yes. I'm working on final changes for packages that will be soon in KDE:Applications

the current RC package that will be submitted to this repo is in my branch: https://build.opensuse.org/package/show/home:krop:applications-24.01.95/kde-inotify-survey

Nothing should have changed since the review

I can confirm that in the upstream Git repository mostly only i18n noise
happened. I will prepare the whitelisting then.

The package name actually stayed the same for kde-inotify-survey. But the
contents of the D-Bus configuration files changed as follows:

--- /usr/share/dbus-1/system-services/org.kde.kded.inotify.service
2024-02-03 03:23:17.000000000 +0100
+++ ./usr/share/dbus-1/system-services/org.kde.kded.inotify.service
2024-02-20 00:48:35.000000000 +0100
@@ -1,4 +1,4 @@
 [D-BUS Service]
 Name=org.kde.kded.inotify
-Exec=/usr/libexec/kauth/kded-inotify-helper
+Exec=/usr/libexec/kf6/kauth/kded-inotify-helper
 User=root

--- /usr/share/dbus-1/system.d/org.kde.kded.inotify.conf        2024-02-03
03:23:17.000000000 +0100
+++ ./usr/share/dbus-1/system.d/org.kde.kded.inotify.conf       2024-02-20
00:48:35.000000000 +0100
@@ -7,5 +7,9 @@
   <policy user="root">
     <allow own="org.kde.kded.inotify"/>
   </policy>
-
+
+  <policy context="default">
+    <allow send_destination="*"/>
+  </policy>
+
 </busconfig>

The latter is not right. This is too open and might affect also other D-Bus
services. Usually this says something like
'<allow send_destination="org.kde.kded.inotify"/>'.

I've overlooked this in the other whitelistings for KDE6. They all use this
new pattern. The reason is found in kauth:

https://invent.kde.org/frameworks/kauth/-/commit/d7916401a335d3a71d617333a471d3c5f20d5cf5

I still have to check the impact of that misconfiguration. If such D-Bus
configuration files from KDE are already used in production somewhere then
this might be CVE material.

(In reply to matthias.gerstner@suse.com from comment #6)
> I still have to check the impact of that misconfiguration. If such D-Bus
> configuration files from KDE are already used in production somewhere then
> this might be CVE material.

I just confirmed that this indeed has a global effect on other D-Bus services.
The details are complex, because the dbus-daemon builds a global configuration
out of all the *.conf snippets found in the directory. I could reproduce it
against our tpm2.0-abrmd package, though. This ships a service that should
only be reachable by "root" or the "tss" user. Once the kde inotify
configuration file is installed, anybody can talk to the tpm-abrmd though.

Filippo, my colleague, digged out the upstream MR# that lead to this commit:

https://invent.kde.org/frameworks/kauth/-/merge_requests/44

There "Marc Deop i Argemí" even suggested the right thing to do, what is
recommended in the D-Bus documentation, but it wasn't done.

We need to involve KDE security with this. This needs to be fixed ASAP. It
also means that we have to touch all the KDE6 whitelistings we already made
_again_. *sigh*.

After the fixes in Kauth the whitelisting for inotify is now also in place.