[SCM] kauth packaging branch, master, updated. debian/5.37.0-2-103-g9185517
Maximiliano Curia
maxy at moszumanska.debian.org
Tue Jan 2 18:28:10 UTC 2018
Gitweb-URL: http://git.debian.org/?p=pkg-kde/frameworks/kauth.git;a=commitdiff;h=f6d1943
The following commit has been merged in the master branch:
commit f6d1943500d8052b923dd53c1f0038f4052ad81b
Author: Harald Sitter <sitter at kde.org>
Date: Thu Apr 28 15:34:59 2016 +0200
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
---
debian/libkf5auth-data.lintian-overrides | 1 +
1 file changed, 1 insertion(+)
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"/>
--
kauth packaging
More information about the pkg-kde-commits
mailing list