summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHarald Sitter <sitter@kde.org>2016-04-28 13:34:59 (GMT)
committerHarald Sitter <sitter@kde.org>2016-04-28 13:34:59 (GMT)
commitf6d1943500d8052b923dd53c1f0038f4052ad81b (patch)
treecfedd4c20a2dea5456757bdade8d316e1d787d1f
parent1424b0152f7001795a04edbea9c534b5b826aa1a (diff)
override dbus-policy-without-send-destination
so I gave this an hour long review and I can't find a reasonable way to exploit this unless someone writes a really daft helper and then a stricter access policy probably won't help either. the purpose of this policy is essentially convenience for application authors not having to register with an actual name on dbus and then installing their own policy basically just whitelisting that name. in reducing the pointless work this probably is even adding security by making it unnecessary for apps to have wildcard rules just because they can't be bothered to harden their helper. so let's look at the details here: - the policy allows anyone to call the org.kde.kf5auth.* - these methods are provided by kauth - the methods are basically generic invokeMethod constructs where one of the arguments is the actual helper-side method to run - before running the helper-side method all requests are run through polkit - once polkit auth is granted the helper proceeds to actually use invokeMethod from Qt to run the method, this implies that the method is either Q_INVOKABLE or Q_SLOTS, you can't just call any old method of the helper - the policy is actually restricting just about all aspects except for the dbus client that is allowed to talk to the interface - ideally each kauth app would still ship their own policy restricting their specific helper to their specific application, but beyond that there isn't much more one could do - even if the sender is restricted that doesn't make much difference unless the sender name is constantly occupied (user-session-long daemon) or the ownership is further restricted to users, which won't work since any user could do this so long as they have polkit rights to so in short: anyone can call kf5auth but that is fine because that interface does polkit checks before doing anything. also you can't call arbitrary methods in the helper due to polkit action ids. if a helper is insecure it would be insecure regardless of this policy
-rw-r--r--debian/libkf5auth-data.lintian-overrides1
1 files changed, 1 insertions, 0 deletions
diff --git a/debian/libkf5auth-data.lintian-overrides b/debian/libkf5auth-data.lintian-overrides
new file mode 100644
index 0000000..aba2b48
--- /dev/null
+++ b/debian/libkf5auth-data.lintian-overrides
@@ -0,0 +1 @@
+libkf5auth-data: dbus-policy-without-send-destination etc/dbus-1/system.d/org.kde.kf5auth.conf <policy context="default"><allow send_interface="org.kde.kf5auth"/>