[SCM] kauth packaging branch, master, updated. debian/5.37.0-2-103-g9185517

[Maximiliano Curia]

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