diff options
| author | Harald Sitter <sitter@kde.org> | 2016-04-28 13:34:59 (GMT) |
|---|---|---|
| committer | Harald Sitter <sitter@kde.org> | 2016-04-28 13:34:59 (GMT) |
| commit | f6d1943500d8052b923dd53c1f0038f4052ad81b (patch) | |
| tree | cfedd4c20a2dea5456757bdade8d316e1d787d1f | |
| parent | 1424b0152f7001795a04edbea9c534b5b826aa1a (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-overrides | 1 |
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"/> |
