Do yo have dbus-x11 package installed?

CC: (none) => jyri2000

Yes, dbus-x11-1.8.14-1.mga5.

Same thing for me. I have built plasma 5 with kdesrc-build, but get the same message. 
IceWM seems to work.

I will check with mga packages.

CC: (none) => yltsparri

Before updating mga packages worked. Ran urpmi --auto-update and got the same message without desktop.

http://kaosx.us/phpBB3/viewtopic.php?f=18&t=777

CC: (none) => mageia, tmb

@Simon:

any thoughts on this?

I see Thiago Macieira from kde has reviewed the hardening patches, so maybe they are aware of the issues ?

CC: (none) => simon.mcvittie

If dbus 1.8.14 is denying messages, you will see messages this in the syslog or systemd Journal:

Jan 06 20:21:14 archetype dbus[967]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.527" (uid=1000 pid=5890 comm="dbus-send --system --dest=org.freedesktop.DBus --t") interface="com.example" member="Nope" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)

For the system bus, these messages go to the systemd Journal on systemd systems, or to the AUTHPRIV syslog (on Debian it's /var/log/auth.log).

For the session bus, these messages might either go to the systemd Journal or to ~/.xsession-errors or somewhere else.

> /usr/libexec/ksyncdbusenv

Yes, this falls foul of the hardening in 1.8.14:

QDBusMessage msg = QDBusMessage::createMethodCall(QStringLiteral("org.freedesktop.DBus"), QStringLiteral("/"), QStringLiteral("org.freedesktop.DBus"), QStringLiteral("UpdateActivationEnvironment"));

The canonical object path for the org.freedesktop.DBus pseudo-service is /org/freedesktop/DBus, although for historical reasons you can call its methods (except for UpdateActivationEnvironment and the Stats interface, since 1.8.14) on any object path. You can tell it's the canonical object path because that's where the NameOwnerChanged signal comes from.

Unfortunately, this is a newer version of KDE than is present in Debian, so my search on codesearch.debian.net indicated that nobody was using other paths for this particular method call.

The risk here is that on the system bus (which is a privilege boundary), incorrect access-control policies like the one resulting in CVE-2014-8148 might allow unauthorized users to call UpdateActivationEnvironment. I initially thought this was a root privilege escalation vulnerability; I now believe it's only a slow denial of service via eating up system dbus-daemon memory, because of some other paranoia in the service-activation code path, but any bug in this area of code is basically a recipe for privilege escalation, so it's a case of "better safe than sorry".

The major difference between the system bus and session bus is exactly the access-control policies, so it isn't trivial to mitigate this for the system bus without also affecting the session bus.

If necessary I can revert the filtering that requires UpdateActivationEnvironment to be called at /org/freedesktop/DBus, because there's an orthogonal mitigation in the same release (only allow UpdateActivationEnvironment to be called by the same uid of the dbus-daemon); but if at all possible I'd prefer to fix KDE instead, because, again, this area is the sort of place where privilege escalations happen, so the more layers of mitigation there are, the happier I am.

> my search on codesearch.debian.net indicated that nobody
> was using other paths for this particular method call

For instance, gnome-session has an example of a call to UpdateActivationEnvironment that does use "/org/freedesktop/DBus" instead of "/".

Don't know if it matters anymore, but I haven't found any dbus reject messages in the journal, in .xsession-errors, or in any other file in /var/log. The DBus daemon is up and all the buses seem to be there (checked with qdbus)

Does Wed Jan 7 12:28:57 2015 UTC dbus-1.8.14-2.mga5 update resolve that problem for Plasma5?

No. I tested it anyway, but it was for an unrelated thing.

I have some progress. 
After installig updates and rerunning kdesrc-build script my custom built plasma 5 desktop works. But Mageia packages continue to have the problem. Maybe some kde package needs rebuild?

Seems ksyncdbusdev was just fixed:

https://projects.kde.org/projects/kde/workspace/plasma-workspace/repository/diff/startkde/ksyncdbusenv/ksyncdbusenv.cpp?rev=c0ace3a3994ab024ba5301b0c6be24a907d57eaf&rev_to=b551c6dbd4490b04a0548f40e4fbd5e1feeb0e0e

So I guess this will be solved with Plasma 5.2

upstream patch backported

This should be fixed with plasma-workspace-5.1.2-7.mga5.

Status: NEW => RESOLVED
CC: (none) => lmenut
Resolution: (none) => FIXED
Source RPM: dbus => plasma-workspace

Awesome, thanks Luc.

Where do I find that package to install from console in Failsafe mode.  KDE hangs boot, and when I do startkde I get the "Could not start D-Bus" message.

Thanks,
Greg

CC: (none) => gseaborn

Hi,

I know this bug is marked as fixed but I am still stuck with it.
My plasma-workspace version is 5.1.2.9.mga5

I can start a failsafe window from SDDM and dbus-launch then startkde but plasma won't start from the DM menu.

Could you help me please.
Thanks,
Richard

CC: (none) => nrgiroux