The default configuration of system.conf in D-Bus (aka DBus) before
1.2.6 omits the send_type attribute in certain rules, which allows
local users to bypass intended access restrictions by (1) sending
messages, related to send_requested_reply; and possibly (2) receiving
messages, related to receive_requested_reply.
This was already being tracked in bug #250444. The security impact on Gentoo systems is minimal at this time due to differences in how Fedora and Gentoo do things.
*** This bug has been marked as a duplicate of bug 250444 ***
We have less system services with dbus interfaces than fedora, but we do not have none, and people might rely on dbus access restrictions for third-party applications, which would still fall under the scope of our security policy.
So I'm reopening this bug for security to track, and the version bump and incompatibility tracker is bug 250444 then.
(In reply to comment #3)
> We have less system services with dbus interfaces than fedora, but we do not
> have none, and people might rely on dbus access restrictions for third-party
> applications, which would still fall under the scope of our security policy.
Not disagreeing with you wrt to 3rd party apps. However, we can ONLY be responsible for what Gentoo ships. There's no way I can guarantee 3rd party apps to be secure. snprintf() can still be used insecurely and we can't be held responsible. The fact that apps don't include PROPER D-Bus configuration files and rely on the default rule is a security flaw in those apps and NOT D-Bus. The issue is about the default rule being too permissive and people relying on that permissiveness and assuming they don't need to setup a proper config.
The issue with the apps that are affected are apps that rely on the default permissive rule, so I would say the real security issue in Gentoo is with those apps and not the default rule.
New upstream mail...
This issue turned out to be quite a lot more wide ranging than I'd
initially thought. It didn't help of course inadvertently pushing
what should have been a testing update into Fedora stable.
Anyways, I think we're going to effectively have a flag day. Some
things were relatively easy to fix, but others are subtle and tricky,
requiring examination of service code.
My current plan on this now, given how much needs to be fixed, is to
do a new upstream release (let's call it 184.108.40.206?) which reverts the
default back to open, *but* adds logging support such that we get a
syslog message when something would have been denied. This should be
a relatively straightforward tweak of the current syslog patch.
In the meantime, there's no reason not to fix your service files now.
Please do so! This mail still applies:
*with the exception* that you must not use bare <deny
send_interface="foo"/> as I initially suggested there. Instead use:
So in summary, get a new release out that lets people (other than me)
figure out more easily what's broken and work on fixing it, without
breaking compatibility for now. Thoughts/opinions?
Voting GLSA no.
voting no too, and closing.