Bug 18229

Created attachment 19870 [details] [review]
Possible fix

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

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.

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

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!

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

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!

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

(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?

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

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

Created attachment 20193 [details] [review]
proposed fix

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

Patch looks good

(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!

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.

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

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?

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.

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

Created attachment 20397 [details] [review]
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.

(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.)

(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.

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.

(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.

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?

(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.

(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.

(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).

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

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

Have you checked the one in our BZ?

Created attachment 20817 [details] [review]
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.

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.

(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!

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.

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?

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.

(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.

(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.

(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?

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

(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.

Note - PackageKit broke with this change:

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

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). 

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

(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...

Created attachment 20899 [details] [review]
Allow-DBus.Introspection-and-DBus.Peer-by-default

This patch allows Introspection and Peer methods by default.

(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.

(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.

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

<allow send_type="signal"/>

Created attachment 20924 [details] [review]
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.

Created attachment 20928 [details] [review]
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.

Created attachment 20942 [details] [review]
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.

(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?

(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.

(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.

(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.

(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.

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)

(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?

(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.

(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?

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