The Plan for CVE-2008-4311

[Colin Walters]

On Tue, Jan 13, 2009 at 1:01 PM, Scott James Remnant
<scott at canonical.com> wrote:
>
> Let me answer this by turning what you said on its head.
>
>
> Every client that sends a method still needs to fill in the destination
> bus name of that method call.  So services on other bus names will never
> even see misdirected/buggy method calls.

Hmmm?  This argument doesn't make sense at all.

Method calls are inherently different from signals because:

1) They are often used to initiate actions, which can be security sensitive
2) They are unicast rather than broadcast by default
2a) By default the bus will deliver a method call to you, because it
has an explicit destination; you don't have to dbus_bus_add_match.
However you *do* have to dbus_bus_add_match for signals (at least,
those not explicitly addressed to you, and the right match rule will
be filtering by sender anyways).
3) It is very clear that DBus' claim to be default deny applied to
methods.  It seems far less clear to me that it applied to signals.

Last I talked to Havoc (who designed/wrote almost all of this) about
signals, I believe he said that his intention was that signals should
be filtered on the recipient end.

What's truly unfortunate about this whole issue is that we aren't
debating what the policy language and semantics should be beforehand;
we're trying to retrofit it after the fact, when projects have already
made a lot of assumptions about how it worked.

> We should take care to make sure that the default D-Bus policy is
> _correct_.

I would state this as that the goal is to determine exactly what the
semantics of the security system are, and where to draw the dividing
line between bugs in the dbus core versus applications.

I believe that the line drawn by the 1.2.8 release stream is a
practical and secure one.

> We actually almost had #1 by accident, and the world didn't end.  It was
> a surprise that we had that, but if we decided that was the right way,
> we could still carry on with it.

What do you mean "almost"?  Look at all of the existing config files;
*none* of them have anything like the rules you'd need if signals were
deny by default.  At least, none on my system.  Virtually everyone had
<allow send_interface="org.foo.MyApp"/> in the default context
(obviously intending it to punch a hole for method calls) which allows
anyone to send any kind of message (including signals) as long as the
interface matches org.foo.MyApp.

>  3. Messages across the bus that are not signals, and claiming bus
>    names, are both denied by default.  But signals are allowed by
>    default.

Read the current system bus security policy below - I think it's
fairly clear.  Let me summarize concisely:  Signals and requested
replies are allowed by default.  Everything else (method calls,
unrequested replies) is denied.

Bus names are actually a separate permission set; I wouldn't mix them
in this discussion.

>    Services that have methods must allow clients to send those methods
>    by context.  Services that require restricted signals deny clients
>    from receiving them.

What service requires restricted signals?  Remember, in the 1.2.8
stream, it's a bug in applications or bindings to not be using match
rules or another mechanism to verify the origin of signals.

> But we've ended up with something that requires both allow and deny,
> depending what type of message you're talking about!

Well, if you look at the current system bus policy, it does not use
<deny> except for one special case relating to
SetActivationEnvironment[1].  Let me just paste it here:

   <!-- Holes must be punched in service configuration files for
         name ownership and sending method calls -->
    <deny own="*"/>
    <allow send_type="method_call" log="true"/>

    <!-- Signals and reply messages (method returns, errors) are allowed
         by default -->
    <allow send_type="signal"/>
    <allow send_requested_reply="true" send_type="method_return"/>
    <allow send_requested_reply="true" send_type="error"/>

    <!-- All messages may be received by default -->
    <allow receive_type="method_call"/>
    <allow receive_type="method_return"/>
    <allow receive_type="error"/>
    <allow receive_type="signal"/>

    <!-- Allow anyone to talk to the message bus -->
    <allow send_destination="org.freedesktop.DBus"/>