Default D-Bus system bus policy is allow

[Scott James Remnant (Canonical)]

A new security release of DBus is now available:

http://dbus.freedesktop.org/dbus/releases/dbus-1.2.6.tar.gz

This release contains a (partial, see below) fix for:
https://bugs.freedesktop.org/show_bug.cgi?id=18229

== Summary ==

Joachim Breitner discovered a mistake in the default configuration for the
system bus (system.conf) which made the default policy for both sent and
received messages effectively *allow*, and not deny as intended.

This release fixes the send side permission, but does not change the receive.
See below for more details.

== Available workarounds ==

Add explicit <deny> rules to existing policy files which do not
already have them.

== Mitigating factors ==

There are three important mitigating factors.

* First, in an examination of a Fedora 10 system, many services contained
explicit <deny> rules under the "default" context. These deny rules did (and
continue to) operate as expected.

* Second, an increasing trend has been for core system services to use
PolicyKit, or otherwise do security checks on the service side. Any system
which relies on PolicyKit is unaffected by this flaw.

* Third, the SELinux DBus support is not affected by this flaw.

Now, as mentioned above this fix is partial. DBus has two kinds of policy
permissions, send and receive. Generally speaking, the send side permission is
much more important. However, DBus has supported receive side permissions for
a few reasons, among those are:

* Ensuring signals containing sensitive data aren't visible by unexpected
processes. Suggested fix: Do not put sensitive data in DBus signals; use
targeted method calls.

* A way for processes to "second-pass" filter messages before they reach their
C code. Suggested fix: Something like PolicyKit (or just manual service-side
permission checks) remain a better way to do this.

For compatibility reasons, this release only fixes the send-side permission
check, and not receive. A greater number of services will need to be updated
for a future tightening of the receive permission.

We are as yet unsure when (and in fact, if) the receive permission will be
tightened in the DBus 1.2 stable branch. We will gather information about any
affected programs and make a final determination at in the near future.

== Conclusion Summary ==

* Add explicit <deny> rules under the default policy if this is applicable to
your service (i.e. not using PolicyKit or similar)
* Do not put sensitive information in signals

== Thanks ==

Thanks to Joachim Breitner for the initial report and proposed patch, Tomas
Hoger for the current fix, and others for their assistance with this issue.
_______________________________________________
dbus mailing list
<email address hidden>
http://lists.freedesktop.org/mailman/listinfo/dbus

[Joachim Breitner (nomeata)]

Created an attachment (id=19870)
Possible fix

I think this (git-format-patch created patch) would fix the problem, but of course it should be reviewed first.

[Hp-pobox (hp-pobox)]

Good catch. I've marked the bug security group only in case people want to do a coordinated update under embargo.

I think the patch is not quite right because <allow> and <deny> should be treated differently.

The requested_reply arg to check_can_send already incorporates whether the message is a reply. So I think perhaps simply removing the "if (dbus_message_get_reply_serial (message) != 0)" check would fix this bug, except the eavesdrop test may need to now look at whether it's a reply, so something like:

if (!requested_reply && rule->allow && rule->d.send.requested_reply)
 {
   if (dbus_message_get_reply_serial (message) != 0 && rule->d.send.eavesdrop)
    {
      /* it's a reply, but was not requested; if eavesdrop is true, allow anyway */
    }
  else
    {
      /* skip rule, do not allow */
      continue;
    }
}

I am not 100% sure though. Clearly more test cases are needed, ideally unit tests for the full matrix of (reply vs. not reply) * (requested vs. not requested) * (allow vs. deny) etc., basically try to cover all the code paths.

[Joachim Breitner (nomeata)]

Hi,

I didn’t expect you would want to embargo this, and submitted it to the public Debian bug tracker as well:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503532

Sorry if that is causing trouble.

Greetings,
Joachim

[Thoger-redhat (thoger-redhat)]

Havoc, do you have any specific <deny> rule example in mind, that would be evaluated incorrectly by dbus if Joachim's patch is applied?

Additionally, is this actually a problem with dbus itself, or rather issue of default policy in system.conf? Reading the dbus-daemon manpage [1], it contains following:

  [1] http://dbus.freedesktop.org/doc/dbus-daemon.1.html

  The [send|receive]_requested_reply attribute works similarly to the
  eavesdrop attribute. It controls whether the <deny> or <allow> matches
  a reply that is expected (corresponds to a previous method call message).
  **This attribute only makes sense for reply messages (errors and method
  returns), and is ignored for other message types.**

If I read it correctly, it basically says: if message type is not error or method return, attribute (not the whole rule) is ignored. So according to that sematics definition, for method call message the rule:

  <allow send_requested_reply="true"/>

should be identical to:

  <allow/>

So the code seems to do exactly what is specified.

Isn't it the default configuration to be blamed for this problem? It says:

  <allow send_requested_reply="true"/>

and expects this rule only to be applied to reply messages. This probably needs to be changed to:

  <allow send_requested_reply="true" send_type="method_return"/>
  <allow send_requested_reply="true" send_type="error"/>

I do understand that Joachim's patch changes semantics for non-reply messages from "attribute is ignored" to "whole rule is ignored".

Additionally, your suggestion does not seem to do the right thing either. Consider call message and rule:

  <allow send_destination="org.designfu.SampleService"/>

If I'm reading the man page correctly, send_requested_reply="true" is implied by default. In that case,

  if (!requested_reply && rule->allow && rule->d.send.requested_reply)

should be true, and

  if (dbus_message_get_reply_serial (message) != 0 && rule->d.send.eavesdrop)

should be false and the rule is skipped.

I'm likely to miss something important, so feel free to correct me in whatever I got wrong. Thanks!

[Hp-pobox (hp-pobox)]

Tomas, I think your analysis is correct. So maybe just change the config file.

[Thoger-redhat (thoger-redhat)]

Havoc, thanks for reviewing my comment!

In comment #2 you stated you may want some coordinated release for this fix along with vendors. Do you have any specific proposed date? The issue is technically public already via Debian bug report (they can't make it private). We do have a pending update to do for bug #17803, so it would be a good opportunity to fix both issues at the same time. Thanks!

[Hp-pobox (hp-pobox)]

If there's coordination, I wouldn't be the person doing it ;-)
(I'd ask johnp or walters or jbressers at Red Hat)

[Thoger-redhat (thoger-redhat)]

(In reply to comment #7)
> If there's coordination, I wouldn't be the person doing it ;-)
> (I'd ask johnp or walters or jbressers at Red Hat)

Ok, so I will take care of it. Is there any date until which you as an upstream would like to keep this private?

[Hp-pobox (hp-pobox)]

No preferred date from me (apparently it isn't truly private anyway)

[Thoger-redhat (thoger-redhat)]

CVE-2008-4311 will be used to identify this flaw.

[Zeuthen (zeuthen)]

Created an attachment (id=20193)
proposed fix

Here's a patch for fixing this via modifying the configuration file. Does this fix the issue? Thanks.

[Hp-pobox (hp-pobox)]

Patch looks good

[Thoger-redhat (thoger-redhat)]

(In reply to comment #11)
> Here's a patch for fixing this via modifying the configuration file. Does this
> fix the issue? Thanks.

This is wrong, your need to use receive_type for rules with receive_requested_reply attribute, otherwise dbus daemon won't even start. Additionally, we will need to spend more time chasing down various apps that rely on the currently used over-permissive policy. When I restarted dbus with this change applied, it killed my kitten^W X session and prevented X login. Ouch!

[Thoger-redhat (thoger-redhat)]

Looks like console-kit-daemon is one to blame, it spew some error messages, one obviously dbus-related:

ConsoleKit open: Unable to open session: A security policy in place prevents this recipient from receiving this message from this sender, see message bus configuration file (rejected message had interface "org.freedesktop.ConsoleKit.Manager" member "OpenSessionWithParameters" error name "(unset)" destination "org.freedesktop.ConsoleKit" reply serial 0 requested_reply=0)

and segfaults.

[Zeuthen (zeuthen)]

Added the ConsoleKit author to the Cc as per comment 14.

[Thoger-redhat (thoger-redhat)]

ConsoleKit will likely need something like this at minimum:

@@ -7,6 +7,11 @@
   <policy user="root">
     <allow own="org.freedesktop.ConsoleKit"/>

+ <!-- Allow receiving of messages to ConsoleKit interfaces -->
+ <allow receive_interface="org.freedesktop.ConsoleKit.Manager"/>
+ <allow receive_interface="org.freedesktop.ConsoleKit.Seat"/>
+ <allow receive_interface="org.freedesktop.ConsoleKit.Session"/>
+
     <!-- Allow all methods on interfaces -->
     <allow send_interface="org.freedesktop.ConsoleKit.Manager"/>
     <allow send_interface="org.freedesktop.ConsoleKit.Seat"/>

But this problem is likely to bite almost any service using system service bus. Looking at the existing configs, even those apps that punch proper holes on the sender side fails to punch holes on receiver side. What is the main reasoning for having to approve each message twice?

So if we want to tighten rule with receive_requested_reply by adding proper message types, almost all service-specific configuration files need to be fixed.

Alternatively, we can do a first half-step towards the full fix and leave that rule as unchanged for now and only turn to stricter rules on sender side (i.e. send_requested_reply rule).

Ideas?

[Thoger-redhat (thoger-redhat)]

Another question is how to deal with messages to some interfaces (such as org.freedesktop.DBus.Introspectable) on the receiver side. There does not seem to be a good way to create receiver rules that would allow receiving of messages to certain interface on one service and deny it on other, as there's not destination-based check for receive rules.

[Thoger-redhat (thoger-redhat)]

Does anyone have any other ideas wrt handling of receive rules?

[Thoger-redhat (thoger-redhat)]

Created an attachment (id=20397)
Possible system.conf change

What about this change for system.conf? It restricts send_requested_reply rule, so it should deal with all unintended method calls. It also tries to set correct expectations wrt future of the receive_requested_reply rule.

This should resolve the problem without need for immediate fix of all applications using system bus. Creating allow receive_interface= rules for all interfaces implemented by any application using the bus would result in a similarly secure policy as one with current receive_requested_reply rule. Not being able to check destination in receive rules still seems quite limiting to me.

[Zeuthen (zeuthen)]

(In reply to comment #19)
> Created an attachment (id=20397) [details]
> Possible system.conf change
>
> What about this change for system.conf? It restricts send_requested_reply
> rule, so it should deal with all unintended method calls. It also tries to set
> correct expectations wrt future of the receive_requested_reply rule.
>
> This should resolve the problem without need for immediate fix of all
> applications using system bus. Creating allow receive_interface= rules for all
> interfaces implemented by any application using the bus would result in a
> similarly secure policy as one with current receive_requested_reply rule. Not
> being able to check destination in receive rules still seems quite limiting to
> me.
>

Colin, Havoc: Are you guys fine with committing Tomas' patch upstream? If not, what kind of work is needed to get this issue resolved in upstream D-Bus?

(I'm asking because I'm wary of putting out an D-Bus errata for Fedora/RHEL without a clear indication that the fix is blessed upstream.)

[Colin Walters (walters)]

(In reply to comment #20)

> Colin, Havoc: Are you guys fine with committing Tomas' patch upstream? If not,
> what kind of work is needed to get this issue resolved in upstream D-Bus?

hp said in comment #5 that the config change is probably right; I haven't had a chance to study this in detail but from reading this report through again it makes sense to me as well.

We should get this fix in.

Tomas - the reason I believe that there's no interface based check is that it's legal for messages to be sent to any interface.

[Colin Walters (walters)]

I vaguely recall a discussion about this that I think ended up at the conclusion that the unit of security granularity should be the service; i.e. not interfaces or methods.

In other words the config file for 3rd party services should just be:

<user="root">
  <allow service="org.freedesktop.ConsoleKit"/>
</user>

This would fit in with the trend of using PolicyKit for more fine grained authorization too.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #21)
> Tomas - the reason I believe that there's no interface based check is that
> it's legal for messages to be sent to any interface.

Sorry, I don't understand this. Proposed patch fixes default rule that is supposed to allow all requested replies. Why should it be bound to any specific interface?

(In reply to comment #22)
> I vaguely recall a discussion about this that I think ended up at the
> conclusion that the unit of security granularity should be the service; i.e.
> not interfaces or methods.

Doesn't this make my note (end of comment #19) about not being able to use destination in receive rules even more valid? Removing possibility to use interface and method attributes will only leave sender, message type and error name checks for use in the receive rules (I believe path falls to the same category as interfaces and methods). So receive rules will have to be wide open to actually work (as they are now).

> In other words the config file for 3rd party services should just be:
>
> <user="root">
> <allow service="org.freedesktop.ConsoleKit"/>
> </user>

Is this supposed to be send or receive rule? Or some new policy concept, that does not distinguish the two any more?

Anyway, if this is expected to be full config for some 3rd party service, dbus will have to get the default configuration right, so that requests from non-root users are denied.

[Colin Walters (walters)]

Should we try to embargo this through vendor-sec, or just go ahead and commit the patch to git under the assumption that since it's already in the Debian BTS it's public?

[Colin Walters (walters)]

(In reply to comment #23)
> (In reply to comment #21)
> > Tomas - the reason I believe that there's no interface based check is that
> > it's legal for messages to be sent to any interface.
>
> Sorry, I don't understand this. Proposed patch fixes default rule that is
> supposed to allow all requested replies. Why should it be bound to any
> specific interface?

I wasn't suggesting the system.conf change should be bound to a specific interface, just that we shouldn't rely on the destination interface in general (there is a note about this in the policy docs).

> (In reply to comment #22)

> Doesn't this make my note (end of comment #19) about not being able to use
> destination in receive rules even more valid? Removing possibility to use
> interface and method attributes will only leave sender, message type and error
> name checks for use in the receive rules (I believe path falls to the same
> category as interfaces and methods). So receive rules will have to be wide
> open to actually work (as they are now).

Right...hm. How useful are the receive rules in general? I guess you'd need them if you wanted to keep a signal private between services.

> > In other words the config file for 3rd party services should just be:
> >
> > <user="root">
> > <allow service="org.freedesktop.ConsoleKit"/>
> > </user>
>
> Is this supposed to be send or receive rule? Or some new policy concept, that
> does not distinguish the two any more?
>
> Anyway, if this is expected to be full config for some 3rd party service, dbus
> will have to get the default configuration right, so that requests from
> non-root users are denied.

I was thinking this policy would allow root to own the service name, and any uid to send&receive messages from it, under the assumption that the service is using PolicyKit for fine grained permissions, or that it makes sense for any uid to be able to access it.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #24)
> Should we try to embargo this through vendor-sec, or just go ahead and commit
> the patch to git under the assumption that since it's already in the Debian BTS
> it's public?

v-s is already aware of this issue, we already passed the previously proposed embargo date and there was not request for extension. Given the Debian bug, I don't think there's any need for further embargo.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #25)
> > Sorry, I don't understand this. Proposed patch fixes default rule that is
> > supposed to allow all requested replies. Why should it be bound to any
> > specific interface?
>
> I wasn't suggesting the system.conf change should be bound to a specific
> interface, just that we shouldn't rely on the destination interface in general
> (there is a note about this in the policy docs).

Do you refer to this: "Be careful with send_interface/receive_interface, because the interface field in messages is optional." ? We don't need this in such a generic rule.

> Right...hm. How useful are the receive rules in general? I guess you'd need
> them if you wanted to keep a signal private between services.

I guess send/receive rules split was made as a design decision for signal handling. For method_calls and method_returns, using single rule making point to point check would be more natural. Having to deal with both type of rules for these types of messages is bit clumsy.

> I was thinking this policy would allow root to own the service name, and any
> uid to send&receive messages from it, under the assumption that the service is
> using PolicyKit for fine grained permissions, or that it makes sense for any
> uid to be able to access it.

Ah, ok. Though this does not sound like a change that can easily fit as a fix into existing systems (some of them even pre-dating PolicyKit).

[Colin Walters (walters)]

Writing a test case for this now. Will work on an upstream release today after that.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #28)
> Writing a test case for this now.

Have you checked the one in our BZ?

[Colin Walters (walters)]

Created an attachment (id=20817)
test case

This patch adds a test case, but doesn't modify the system policy yet. I chose to use Tomas' suggested policy for the test case policy, and I get the expected denial.

[Colin Walters (walters)]

Ok, now I've double checked with this patch that the rules:

    <allow send_requested_reply="true"/>
    <allow send_requested_reply="true"/>
    <allow receive_requested_reply="true"/>

Allow the message through (incorrectly), whereas:

    <allow send_requested_reply="true" send_type="method_return"/>
    <allow send_requested_reply="true" send_type="error"/>
    <allow receive_requested_reply="true"/>

Disallow the message.

A quick once over of this patch would be appreciated; once that's done I'll merge it and then change the system.conf.in to match it per Tomas' patch.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #31)

> A quick once over of this patch would be appreciated; once that's done I'll
> merge it and then change the system.conf.in to match it per Tomas' patch.

Is there any other patch to look at besides the one in comment #30? Test test config has differences to my proposed patch, so some thoughts on them:

- It also restricts receive_requested_reply rule. While this change really turns default config to what it claims to be, it also breaks existing stuff badly and has questionable benefits.

- I guess there should be some note used there, so that the config is at honest at what it claims, and make users aware it may get better fix in the future. Feel free to re-word my note as needed.

Thank you!

[Colin Walters (walters)]

Proposed text of mail announcement:

Subject: [CVE-2008-4311] DBus 1.2.6

A new security release of DBus is now available:

http://dbus.freedesktop.org/dbus/releases/dbus-1.2.6.tar.gz

This release contains a (partial, see below) fix for: https://bugs.freedesktop.org/show_bug.cgi?id=18229

== Summary ==

Because of a mistake in the default configuration for the system bus (system.conf), the default policy for both sent and received messages was effectively *allow*, and not deny as stated.

This release fixes the send side permission, but does not change the receive. See below for more details.

== Available workarounds ==

It is possible to add explicit <deny> rules to existing policy files, and in fact many have these already.

== Mitigating factors ==

There are three important mitigating factors.

* First, in an examination of a Fedora 10 system, many services (though not all, see below) contained explicit <deny> rules. These deny rules did (and continue to) operate as expected.

* Second, an increasing trend has been for core system services to use PolicyKit, or otherwise do security checks on the service side. Any system which relies on PolicyKit is unaffected by this flaw.

* Third, the SELinux DBus support is not affected by this flaw.

Now, as mentioned above this fix is partial. DBus has two kinds of policy permissions, send and receive. Generally speaking, the send side permission is much more important. However, DBus has supported receive side permissions for a few reasons, among those are:

* Ensuring signals containing sensitive data aren't visible by unexpected processes
* A way for processes to "second-pass" filter messages before they reach their C code; however, what one can do in the policy language is relatively limited, and something like PolicyKit (or just manual service-side permission checks) remain a better way to do this.

For compatibility reasons, this release only fixes the send-side permission check, and not receive. A greater number of services will need to be updated for a future tightening of the receive permission.

We are as yet unsure when (and in fact, if) the receive permission will be tightened in the DBus 1.2 stable branch. We will gather information about any affected programs and make a final determination at in the near future.

For now, it is suggested to use explicit <deny> rules for receive side.

[Colin Walters (walters)]

Further note will send after:

== Affected Services ==

An examination of a Fedora 10 desktop installation discovered only one affected program, the APT backend for PackageKit.

A fix is available here:

[link here]

Does anyone know of any other affected programs?

[Colin Walters (walters)]

A few updates; credits, stronger suggestion to always use <deny>.

Subject: [CVE-2008-4311] DBus 1.2.6

A new security release of DBus is now available:

http://dbus.freedesktop.org/dbus/releases/dbus-1.2.6.tar.gz

This release contains a (partial, see below) fix for:
https://bugs.freedesktop.org/show_bug.cgi?id=18229

== Summary ==

Joachim Breitner discovered a mistake in the default configuration for the system bus (system.conf) which made the default policy for both sent and received messages was effectively *allow*, and not deny as stated.

This release fixes the send side permission, but does not change the receive.
See below for more details.

== Available workarounds ==

It is possible to add explicit <deny> rules to existing policy files, and in
fact many have these already.

== Mitigating factors ==

There are three important mitigating factors.

* First, in an examination of a Fedora 10 system, many services contained explicit <deny> rules. These deny rules did (and
continue to) operate as expected.

* Second, an increasing trend has been for core system services to use
PolicyKit, or otherwise do security checks on the service side. Any system
which relies on PolicyKit is unaffected by this flaw.

* Third, the SELinux DBus support is not affected by this flaw.

Now, as mentioned above this fix is partial. DBus has two kinds of policy
permissions, send and receive. Generally speaking, the send side permission is
much more important. However, DBus has supported receive side permissions for
a few reasons, among those are:

* Ensuring signals containing sensitive data aren't visible by unexpected
processes. Suggested fix: Do not put sensitive data in DBus signals; use targeted method calls.

* A way for processes to "second-pass" filter messages before they reach their
C code. Suggested fix: Something like PolicyKit (or just manual service-side permission checks) remain a better way to do this.

For compatibility reasons, this release only fixes the send-side permission
check, and not receive. A greater number of services will need to be updated
for a future tightening of the receive permission.

We are as yet unsure when (and in fact, if) the receive permission will be
tightened in the DBus 1.2 stable branch. We will gather information about any
affected programs and make a final determination at in the near future.

== Conclusion Summary ==

* Add explicit <deny> rules under the default policy if this is applicable to your service (i.e. not using PolicyKit or similar)
* Do not put sensitive information in signals

== Thanks ==

Thanks to Joachim Breitner for the initial report and proposed patch, Tomas Hoger for the current fix, and others for their assistance with this issue.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #34)
> Does anyone know of any other affected programs?

bluetooth.conf in bluez-utils only permit some messages from at_console users, with no restriction for context=default, so looks affected.

[Colin Walters (walters)]

(In reply to comment #36)
> (In reply to comment #34)
> > Does anyone know of any other affected programs?
>
> bluetooth.conf in bluez-utils only permit some messages from at_console users,
> with no restriction for context=default, so looks affected.

Ok, I'll try to touch base with them now and see if they can get an update ready.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #37)
> > bluetooth.conf in bluez-utils only permit some messages from at_console
> > users, with no restriction for context=default, so looks affected.
>
> Ok, I'll try to touch base with them now and see if they can get an update
> ready.

Update bluez? Why? Once dbus default policy is right, there will be no need for explicit denies in bluez. Or have I managed to misunderstand what you referred to as affected programs?

[Colin Walters (walters)]

Release done, lifting security tag. I'll keep this bug open as a data gathering point for what to do about the receive aspect.

[Colin Walters (walters)]

(In reply to comment #38)
> (In reply to comment #37)
> > > bluetooth.conf in bluez-utils only permit some messages from at_console
> > > users, with no restriction for context=default, so looks affected.
> >
> > Ok, I'll try to touch base with them now and see if they can get an update
> > ready.
>
> Update bluez? Why? Once dbus default policy is right, there will be no need
> for explicit denies in bluez.

Right, it's not strictly speaking necessary, it just seems prudent to add the <deny> rules.

Even besides that it seems important to touch base with those projects without the <deny>, simply because they were affected and should be aware of the impact.

[Colin (colin-redhat-bugs)]

See:
https://bugs.freedesktop.org/show_bug.cgi?id=18229

[Fedora (fedora-redhat-bugs)]

dbus-1.2.6-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/dbus-1.2.6-1.fc10

[Fedora (fedora-redhat-bugs)]

dbus-1.2.6-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

[Fedora (fedora-redhat-bugs)]

dbus-1.2.6-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.

[Colin Walters (walters)]

Note - PackageKit broke with this change:

https://bugs.freedesktop.org/show_bug.cgi?id=18931

[Sjoerd Simons (sjoerd)]

avahi-daemon also breaks. It has several dbus interface from which it sends signals which are denied with this fix. Most of those interface also have methods but those should work correctly as it has <allow send_destination="org.freedesktop.Avahi"/>. The easiest way to test for this is by running avahi-discover.

I'll try to investigate the minimal fix tomorrow (if time allows, feel free to beat me to it).

[Thoger-redhat (thoger-redhat)]

PolicyKit policy bug:
  https://bugs.freedesktop.org/show_bug.cgi?id=18948

[Thoger-redhat (thoger-redhat)]

(In reply to comment #42)
> avahi-daemon also breaks. It has several dbus interface from which it sends
> signals which are denied with this fix.

What is the interface used in the signals? org.freedesktop.Avahi? Probably adding:

  <allow send_interface="org.freedesktop.Avahi"/>

to the <policy group="avahi"> section should be the easiest fix (well, it may be better to bound it to the owner of the org.freedesktop.Avahi name as a sender, but that can't be done in the send rules). On the receiver side, following already existing context="default" rule should be sufficient:

  <allow receive_sender="org.freedesktop.Avahi"/>

As for the fix proposed here:
  http://lists.freedesktop.org/archives/dbus/2008-December/010706.html
  <allow send_requested_reply="true" send_type="signal"/>

This rule will only be considered for messages of type signal. send_requested_reply attribute will be ignored, so the rule will allow sending any signal, by any service connected to the bus (not only avahi-daemon).

Not quite sure what to look for in the avahi-discover output...

[Colin Walters (walters)]

Created an attachment (id=20899)
Allow-DBus.Introspection-and-DBus.Peer-by-default

This patch allows Introspection and Peer methods by default.

[Zeuthen (zeuthen)]

(In reply to comment #45)
> Created an attachment (id=20899) [details]
> Allow-DBus.Introspection-and-DBus.Peer-by-default
>
> This patch allows Introspection and Peer methods by default.
>

Hmm. I honestly think this is confusing. If we require that system services need to punch holes *anyway*, why not let them punch holes for Peer and Introspectable too?

I think doing this automatically will just make it even harder to grasp how to use <allow> and <deny> correctly; it's already way too overcomplicated and we've seen both the implementation and users get it wrong.

[Colin Walters (walters)]

(In reply to comment #46)
> (In reply to comment #45)
> > Created an attachment (id=20899) [details] [details]
> > Allow-DBus.Introspection-and-DBus.Peer-by-default
> >
> > This patch allows Introspection and Peer methods by default.
> >
>
> Hmm. I honestly think this is confusing. If we require that system services
> need to punch holes *anyway*, why not let them punch holes for Peer and
> Introspectable too?
>
> I think doing this automatically will just make it even harder to grasp how to
> use <allow> and <deny> correctly; it's already way too overcomplicated and
> we've seen both the implementation and users get it wrong.

I think the bottom line is to use send_destination liberally. I'll post about this on the list.

[Colin Walters (walters)]

There is one major issue left to address: signals. Basically, we should add a global

<allow send_type="signal"/>

[Colin Walters (walters)]

Created an attachment (id=20924)
cleanup of system.d

Here is a first pass through the system.d directory. The major themes are:

* Changing things to use send_destination. This fixes the introspection handling.
* Removing rules of the form <deny send_interface="org.foo.Bar"/>. These are actively harmful and break introspection - see bug 18961. I also took the opportunity to remove rules that should be redundant now.
* Adding missing <context="default"><allow send_destination="com.foo.Baz"/> rules.

[Feng (feng-redhat-bugs)]

This version of dbus messes up everything:

gpk stops working,
system-config-services stops working,
system-config-printer stops working,

and more.

Seems like some default policy were changed, and the corresponding system components were not tweaked.

Refer to this link:

http://forums.fedoraforum.org/showthread.php?t=206797

[Colin Walters (walters)]

Created an attachment (id=20928)
allow signals by default

In order to move forward with the system.d cleanup, I propose we allow all signals by default. There is not great value in restricting the namespaces of sent signals.

[Scott James Remnant (Canonical) (canonical-scott)]

Binary package hint: dbus

From <email address hidden> Fri Dec 5 19:55:35 2008
Return-path: <email address hidden>
Envelope-to: <email address hidden>
Delivery-date: Fri, 05 Dec 2008 19:55:35 +0000
Received: from fiordland.canonical.com ([91.189.94.145]) by
 zelda.netsplit.com with esmtp (Exim 4.69) (envelope-from
 <email address hidden>) id 1L8glz-0008Lu-Jr for
 <email address hidden>; Fri, 05 Dec 2008 19:55:35 +0000
Received: from cluster-e.mailcontrol.com (cluster-e.mailcontrol.com
 [85.115.58.190]) by fiordland.canonical.com (Postfix) with ESMTP id
 A2228B68256; Fri, 5 Dec 2008 19:55:12 +0000 (GMT)
Received: from arctowski.canonical.com (arctowski.canonical.com
 [91.189.94.158]) by rly14e.srv.mailcontrol.com (MailControl) with ESMTP id
 mB5JtBXk031219; Fri, 5 Dec 2008 19:55:11 GMT
Received: from fiordland.canonical.com ([91.189.94.145]) by
 arctowski.canonical.com with esmtp (Exim 4.60) (envelope-from
 <email address hidden>) id 1L8glb-0005dd-Id; Fri, 05 Dec 2008
 19:55:11 +0000
Received: from gabe.freedesktop.org (gabe.freedesktop.org
 [131.252.210.177]) by fiordland.canonical.com (Postfix) with ESMTP id
 C49C8B68256; Fri, 5 Dec 2008 19:55:10 +0000 (GMT)
Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by
 gabe.freedesktop.org (Postfix) with ESMTP id 7EA2C9E8BE; Fri, 5 Dec 2008
 11:55:08 -0800 (PST)
X-Original-To: <email address hidden>
Delivered-To: <email address hidden>
Received: from an-out-0708.google.com (an-out-0708.google.com
 [209.85.132.249]) by gabe.freedesktop.org (Postfix) with ESMTP id
 D3FBB9E741 for <email address hidden>; Fri, 5 Dec 2008 11:55:05
 -0800 (PST)
Received: by an-out-0708.google.com with SMTP id d11so111353and.39 for
 <email address hidden>; Fri, 05 Dec 2008 11:55:05 -0800 (PST)
Received: by 10.100.242.20 with SMTP id p20mr252471anh.75.1228506904963;
 Fri, 05 Dec 2008 11:55:04 -0800 (PST)
Received: by 10.100.127.20 with HTTP; Fri, 5 Dec 2008 11:55:04 -0800 (PST)
Message-ID: <email address hidden>
Date: Fri, 5 Dec 2008 14:55:04 -0500
From: "Colin Walters" <email address hidden>
To: dbus <email address hidden>
Subject: [CVE-2008-4311] DBus 1.2.6
MIME-Version: 1.0
Content-Disposition: inline
X-Google-Sender-Auth: 916061a5b371d5d2
X-BeenThere: <email address hidden>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dbus.lists.freedesktop.org>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/listinfo/dbus>,
 <mailto:<email address hidden>?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dbus>
List-Post: <mailto:<email address hidden>>
List-Help: <mailto:<email address hidden>?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dbus>,
 <mailto:<email address hidden>?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: <email address hidden>
Errors-To: <email address hidden>
X-Mailcontrol-Inbound:
 uq3drnD2P+ps5SfEb0fvr78+NoP1DHBZwGqKpaXB2eTgNv8D6KLIxb8+NoP1DHBZ8VSaBg0k0xw=
X-Spam-Score: -3.5
X-Scan...

[Scott James Remnant (Canonical) (canonical-scott)]

This change is known to break many of the existing D-Bus services, most notably Avahi, PolicyKit and PackageKit. It's also believed to break signals.

While upstream figure out what to do about that, we've looked into the actual effect of the problem.

The most concerning system bus service would be system-tools-backend, however that has explicit <deny> rules, so should not be affected.

Other pieces already use PolicyKit.

Thus we're happy that there's no significant exploit here, and that there is too great a risk for breaking existing services with the current patch. We'll make an upload as soon as the situation is clear.

[Thoger-redhat (thoger-redhat)]

Created an attachment (id=20942)
Improvement for dbus-daemon manpage wrt policy rule application ordering

Colin, can you please consider this minor dbus-daemon man page improvement for next update? It adds mention of at_console <policy> attribute.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #50)
> In order to move forward with the system.d cleanup, I propose we allow all
> signals by default. There is not great value in restricting the namespaces of
> sent signals.

Should receiving of all signals be allowed by default as well? Are there any known use-cases of private signals?

[Thoger-redhat (thoger-redhat)]

(In reply to comment #49)
> Here is a first pass through the system.d directory.

Some thoughts...

--- system.d/avahi-dbus.conf

There are few receive_sender rules there as well that should only be needed for signals, so their fate actually depends on what the default for signals will be.

--- system.d/ConsoleKit.conf

Did you leave user="root" rules unchanged intentionally? They look like a good candidate for allow send_destination. Why not remove all those context="default" deny rules and only keep explicit allows.

The similar comments apply to gdm.conf.

--- system.d/dnsmasq.conf

Rule <allow send_interface="uk.org.thekelleys.dnsmasq"/> should only be needed for signal sending, so is candidate for removal if signals are permitted by default.

--- system.d/newprinternotification.conf

- <allow send_interface="com.redhat.NewPrinterNotification"/>

Again, may be needed for signals.

--- system.d/org.fedoraproject.Config.Services.conf

I'd prefer to see allow send_destination rule removed from user="root" section. All context="default" rules apply to root as well, so having the rule only there should be sufficient.

--- system.d/org.gnome.ClockApplet.Mechanism.conf

This seems incorrect to me. Probably something like this is needed:

@@ -8,12 +8,12 @@
   <!-- Only root can own the service -->
   <policy user="root">
     <allow own="org.gnome.ClockApplet.Mechanism"/>
- <allow send_interface="org.gnome.ClockApplet.Mechanism.SetTimezoneInterface"/>
   </policy>

   <!-- Allow anyone to invoke methods on the interfaces -->
   <policy context="default">
- <allow send_interface="org.gnome.ClockApplet.Mechanism.SetTimezoneInterface"/>
+ <allow send_destination="org.gnome.ClockApplet.Mechanism"
+ send_interface="org.gnome.ClockApplet.Mechanism.SetTimezoneInterface"/>
   </policy>

 </busconfig>

Not sure if binding to a particular interface is really needed.

--- system.d/org.gnome.*

Allow rules in user="root" section can be omitted when service should be accessible to all users and there's context="default" allow rule.

--- system.d/setroubleshootd.conf

It may requires some of the removed rules, or allow receive_sender rule for signal handling.

Similar probably applies to yum-updatesd.conf as well.

[Colin Walters (walters)]

(In reply to comment #52)
> (In reply to comment #50)
> > In order to move forward with the system.d cleanup, I propose we allow all
> > signals by default. There is not great value in restricting the namespaces of
> > sent signals.
>
> Should receiving of all signals be allowed by default as well? Are there any
> known use-cases of private signals?
>

I believe receiving signals will be covered by the receive_requested_reply opening all receive side.

[Colin Walters (walters)]

(In reply to comment #51)
> Created an attachment (id=20942) [details]
> Improvement for dbus-daemon manpage wrt policy rule application ordering
>
> Colin, can you please consider this minor dbus-daemon man page improvement for
> next update? It adds mention of at_console <policy> attribute.

Will do, I also have an update to the man page lying around.

[Thoger-redhat (thoger-redhat)]

(In reply to comment #54)
> > Should receiving of all signals be allowed by default as well? Are there any
> > known use-cases of private signals?
>
> I believe receiving signals will be covered by the receive_requested_reply
> opening all receive side.

Oh, well, that's correct. Looks like I was thinking too long-term, assuming complete fix.

[Colin Walters (walters)]

Thanks for the review of the system.d changes. Let's actually break this list up into 3 separate parts:

1) Services broken by the new security policy (e.g. the original PolicyKit.conf could never have worked in a default-deny world)
2) Services which use <deny send_interface/> without also specifying send_destination. These break no-interface requests from scripting languages.
3) Cleanup

Suggest we focus on these in order. I've created tracking bugs:

Broken: https://bugs.freedesktop.org/show_bug.cgi?id=18980
Deny send_interface: https://bugs.freedesktop.org/show_bug.cgi?id=18961
Cleanup: (We'll do this later)

[Dan Ziemba (zman0900)]

(In reply to comment #34)
>
> Does anyone know of any other affected programs?
>

I am a Fedora 10 user, and I have been following this bug. My system is running the updated dbus, and I have noticed two other affected applications: system-config-services and system-config-samba. It looks as though s-c-services has already been addressed in the system.d patch, but I think there is something wrong in the org.fedoraproject.Config.Samba.conf file for s-c-samba. The file is identical to the org.fedoraproject.Config.Services.conf file except for the word Services, so I assume the same fix could be used on it?

[Dan Ziemba (zman0900)]

(In reply to comment #58)
> (In reply to comment #34)
> >
> > Does anyone know of any other affected programs?
> >
>
> I am a Fedora 10 user, and I have been following this bug. My system is
> running the updated dbus, and I have noticed two other affected applications:
> system-config-services and system-config-samba. It looks as though
> s-c-services has already been addressed in the system.d patch, but I think
> there is something wrong in the org.fedoraproject.Config.Samba.conf file for
> s-c-samba. The file is identical to the org.fedoraproject.Config.Services.conf
> file except for the word Services, so I assume the same fix could be used on
> it?
>

Nevermind, I see that new versions of each have been build on Koji. I have tested them both and the seem to work.

[Scott James Remnant (Canonical) (canonical-scott)]

A new release of DBus is now available:

http://dbus.freedesktop.org/dbus/releases/dbus-1.2.8.tar.gz
SHA1: f6a5215b1eb6fee17821beb22f2e934ad383bfbe

This release is a continuation of work on:
https://bugs.freedesktop.org/show_bug.cgi?id=18229

== Overview ==
I think we're finally arriving at general consensus for where the line
for bugs in the core is versus in external programs for this issue.

DBus 1.2.8 has one behavioral change, which is to allow all signals by
default on the system bus. There is also a documentation update for
the system bus:

"Currently, the system bus has a default-deny policy for sending method calls
and owning bus names. Everything else, in particular reply messages, receive
checks, and signals has a default allow policy."

There are two major things to be aware of, in order of importance:

== Services ==
Now, corresponding with this issue, some services must be updated. A
tracking bug has been created:
https://bugs.freedesktop.org/show_bug.cgi?id=18980

The above bug is for services which fail with the policy for DBus
1.2.8 (i.e. not 1.2.6).

== <deny send_interface=""/>
Besides services which must be updated to work, there are also
services whose config breaks *other* services or introduces erroneous
permissions. This kind of flaw is really the fault of the policy
language - it's incredibly easy to introduce these kinds of flaws. In
general, every rule in a system.d/foo.conf should include
"send_destination". If it doesn't, it's almost certainly a bug.

The most insidious is this one:

<policy context="default">
  <deny send_interface="org.foo.Iface"/>
</policy>

Effectively, this will deny all messages sent with no interface - even
those *not sent to your service* - as occurs when using e.g. Python
and not using the dbus.Interface cast. The correct rule looks like
this:

<policy context="default">
  <deny send_destination="org.foo.Service" send_interface="org.foo.Iface"/>
</policy>

Bottom line - use send_destination in *every* rule unless you know
explicitly what you're doing, and avoid putting two services in the
same process (if you do, use PolicyKit).

[Scott James Remnant (Canonical) (canonical-scott)]

Here's the technical summary:

The D-Bus protocol is made up of messages, the basic types of which are "method call", "reply", "error" and "signal".

Messages are policy-checked by the bus daemon. To be allowed, the message must past both the "send" rules (for the client) and the "receive" rules (for the service).

A method call is thus two messages: the "method call" sent from the client to the service, and a "reply" or "error" sent back from the service to the client. The client must have permission to send the "method call", and receive both "reply" and "error". The service must have permission to receive the "method call", and send both "reply" and "error".

A signal is a signal message: the "signal" is sent from a service to clients. The service must have permission to send the "signal". The clients must have permission to receive the "signal".

--

Policy is specified by a series of <allow> and <deny> rules for particular policy contexts (default, by user, etc.), and is in the /etc/dbus-1/system.conf file and the various service /etc/dbus-1/system.d/*.conf files.

The daemon simply concatenates the rules, it doesn't distinguish that a certain file comes from a certain service, etc. Remember that: it's important.

Since every message is checked for both send *and* receive, in practice, you only need to test one side of this. The standard so far has been to allow clients to send the message to you:

Here's an example for a typical service, this example is pastable:

  <policy user="root">
    <allow own="com.ubuntu.RoomService"/>
  </policy>

  <policy context="default">
    <allow send_destination="com.ubuntu.RoomService"/>
  </policy>

This allows the "root" user to own the "com.ubuntu.RoomService" bus name; and allows any user to send method calls to it.

If you wanted to restrict some method calls, you might do something like:

  <policy user="root">
    <allow own="com.ubuntu.RoomService"/>
    <allow send_destination="com.ubuntu.RoomService"/>
  </policy>

  <policy context="default">
    <allow send_destination="com.ubuntu.RoomService"/>
    <deny send_destination="com.ubuntu.RoomService" send_member="EvictGuest"/>
  </policy>

Note that we explicitly qualified the deny with a "send_destination"; otherwise we'd have denied the EvictGuest method call to *any* service, not just our own - which might be a different interface, or a different service entirely.

There is a case for using receive policy rules, restricting who can receive signals (which are otherwise allowed). For example, to only allow root to receive a signal:

  <policy user="root">
    <allow own="com.ubuntu.RoomService"/>
    <allow receive_sender="com.ubuntu.RoomService" receive_type="signal">
  </policy>

  <policy context="default">
    <allow send_destination="com.ubuntu.RoomService"/>
    <deny receive_sender="com.ubuntu.RoomService" receive_type="signal">
  </policy>

ie. root can own the bus name, and can receive signals from RoomService; everyone else can send method calls to RoomService but cannot receive signals from it.

Again note that we qualify with the sender, we don't want to deny signals from other services.

--

The above assumes that the def...

[Scott James Remnant (Canonical) (canonical-scott)]

Bug for signal injection:

http://bugs.freedesktop.org/show_bug.cgi?id=18982

[Scott James Remnant (Canonical) (canonical-scott)]

screen-resolution-extra: https://bugs.edge.launchpad.net/ubuntu/+source/screen-resolution-extra/+bug/306705

[Scott James Remnant (Canonical) (canonical-scott)]

eggcups: bug #306716

[Scott James Remnant (Canonical) (canonical-scott)]

gpe-bluetooth: bug #306726

[Scott James Remnant (Canonical) (canonical-scott)]

kerneloops: bug #306728

[Launchpad Janitor (janitor)]

This bug was fixed in the package dbus - 1.2.12-0ubuntu1

---------------
dbus (1.2.12-0ubuntu1) jaunty; urgency=low

  * New upstream release: (LP: #306362)
    - Correct default configuration to deny sending messages that are not
      signals or expected replies. [CVE-2008-4311]a
    - Default system bus policy cleaned up and clarified.
    - Add system logging of method denials and config file reloads.
    - Abstract sockets not tested for if explicitly disabled.
    - More efficient validation for fixed-size type arrays.
    - Serial printed by dbus-monitor.
    - New --address option for dbus-send

 -- Scott James Remnant <email address hidden> Fri, 16 Jan 2009 11:03:53 +0000

[Joachim Breitner (nomeata)]

(In reply to comment #39)
> Release done, lifting security tag. I'll keep this bug open as a data
> gathering point for what to do about the receive aspect.

I’m just going through my bugs here, and noticed this one. Is there still stuff to do or can this bug be closed?

[Richard Hughes (richard-hughes)]

Yes. I think we can close this now. Thanks.