The Plan for CVE-2008-4311

[Scott James Remnant]

On Tue, 2009-01-13 at 10:08 -0500, Colin Walters wrote:

> > If deny is the default for signals, then services simply do:
> >
> > <allow sender="org.freedesktop.Hal"
> >       send_interface="org.freedesktop.Hal"/>
> 
> Yes, but again regardless - every signal recipient still needs to
> check the origin of signals.  Or more precisely, the best approach is
> for bindings/apps to use the match rules and so the process will never
> even see malicious or misdirected/buggy signals.
> 
> So denying signals isn't improving security, and thus it's not clear
> to me what we're gaining by it.
> 
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.

So denying method calls isn't improving security.


> The other argument is that we've already released dbus 1.2.6+, and in
> Fedora we've been modifying service files.  I'm *really* hesitant to
> change the story again for questionable gain.
> 
The fact that RedHat sat on the D-Bus issue for a month without taking
action, and then leapt into a series of knee-jerk reactions that
ultimately proved to cause problems is, well, not really for debate
here ;)

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


I think there are two sane options:

 1. Messages across the bus are allowed by default, but claiming bus
    names is not allowed by default.

    Services that require restricted methods deny clients from sending
    them.  Services that require restricted signals deny clients from
    receiving them.

    Security is ensured because method calls are always sent with a
    destination bus name in mind (and malicious services can't claim
    those), and signals are always sent from a origin bus name and
    receives match them.


 2. Messages across the bus, and claiming bus names, are both denied by
    default.

    Services that have methods must allow clients to send those methods
    by context.  Services that send signals must allow clients to
    receive those signals by context.

    Security is ensured because only those things we chose to allow are
    allowed.  Clients don't have to worry about the destination or
    origin bus name, because only those permitted by the bus are allowed
    anyway.


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.

(Security of bus name)

But what we've ended up with now is neither.

We have a strange #3

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

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

    Security is ensured for method calls because they are always send
    with a destination bus name in mind (and malicious services can't
    claim those) *and* the bus doesn't pass them unless explicitly
    allowed anyway.

    Security is ensured for signals because they are always sent from an
    origin bus name, and receives match them.  But if the receives fail
    to match them, then the bus will allow them, and security is not
    ensured.


> Oh and the service language would *not* have <deny>.  I think SELinux
> really got it right by not having both <allow> and <deny> rules.
> 
I utterly agree here.  This is basically my point.

We should have an "allow-by-default" policy (#1) except for claiming bus
names, *or* a "deny-by-default" policy (#2).  If we chose #1, we'd throw
away allow; if we chose #2, we'd throw away deny.

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


I do not think this is good.

Scott
-- 
Scott James Remnant
scott at canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090113/6b183cde/attachment.pgp