Disabling new D-Bus protocol features by default

David Zeuthen zeuthen at gmail.com
Tue Nov 9 14:29:05 PST 2010


Hi,

On Mon, Nov 8, 2010 at 12:20 PM, Thiago Macieira <thiago at kde.org> wrote:
> I'd like to disable the Unix FD passing by default in libdbus-1.
>
> The reason for this is that when running against old application and binding
> code, receiving a message containing an FD causes unpredictable results.
> Bindings are often written to assume they can understand any type thrown at
> them, so they might throw a fit if they see a type they don't know.

As many others, I'm opposed to this. If applications or, worse,
bindings are written in a way such that they don't perform checks
before interpreting data read off the wire, then the application
really needs to be fixed. Regardless of whether Unix FD passing is
enabled or not.

I mean, we're talking about dealing with UNTRUSTED DATA here which in
the system bus case is typically a privileged app dealing with an
unprivileged app. Which means that no matter what, the application
MUST be written with paranoia in mind. Which _specifically_ means
checking the signature of the incoming message before parsing the
payload.

In another mail:
> Now we know that new types can be added, so new code will probably
> be written to accommodate this. I'm not so sure of existing code, since
> there was no hint in the spec that new types could ever be added.

Nah, claiming that the D-Bus spec was set in stone will not hold water
in the court, sorry.

First, the spec specifically says "only compatible extensions are
allowed". Second, from very early on e.g. NDesk extended its private
use of D-Bus to include type 'f' (for float). Which has been discussed
on this list quite a bit. Third, I mean... come on! We are all
programmers. Which means that we evolve interfaces _all_ the time! So
being all lawyer-ish and claiming "oh, we didn't explicitly said more
types could be added" is just a bit weird. It's also (per the first
point) simply not true ("only compatible extensions are allowed").

In another mail you wrote:
> Crashing ConsoleKit, PolicyKit, Hal, Avahi or other system services from a
> non-privileged connection sounds serious to me.

Do you have any evidence this is actually so if using a
Unix-FD-passing capable daemon and connection? FWIW, I'm very
confident that it does not follow and that these apps work just
fine...

(BTW, I'm not saying these apps are perfect - like other apps they
contain bugs and we fix crasher/security bugs from time to time like
any other project. I'm just saying that with the way these apps are
written, they are already written in a paranoid way etc. etc. Also:
PolicyKit is no longer using libdbus-1 - the latest released version
is using GDBus.)

Sorry if this mail is non-constructive. To be a bit constructive, let
me ask this: Do you have any reason to believe that existing bindings
or apps can't be fixed to do the checking they need to do?

Thanks,
David


More information about the dbus mailing list