Debian Bug report logs - #510644
bluetooth.conf needs alterations for new D-Bus

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: bluetooth.conf needs alterations for new D-Bus

Date: Sun, 4 Jan 2009 01:29:44 +0000

[Message part 1 (text/plain, inline)]

Package: bluez-utils
Version: 3.36-2
Severity: serious
Justification: blocker for #503532 (CVE-2008-4311) and far-fetched security hole
Tags: fixed-upstream
User: pkg-utopia-maintainers@lists.alioth.debian.org
Usertags: CVE-2008-4311

bluez-utils installs a D-Bus system policy file intending to allow users
at the console to send BlueZ messages to hcid. However, it actually
allows users at the console to send messages to the object path '/' on
any service, slightly subverting access control for those other services.

Furthermore, it might be insufficient to allow everything that hcid intends to
allow; messages used to be allowed accidentally by a dbus-daemon bug, but
with the dbus-daemon changes targeted for lenny, they will be denied
unless explicitly allowed.

<http://git.kernel.org/?p=bluetooth/bluez.git;a=history;f=src/bluetooth.conf;h=c0476237;hb=fb333f1c>
shows the recent history of this file - the latest version,
<http://git.kernel.org/?p=bluetooth/bluez.git;a=blob;f=src/bluetooth.conf;hb=06637b08>,
appears to be appropriate.

Regards from the Cambridge BSP,
    Simon

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Filippo Giunchedi <filippo@debian.org>

To: Simon McVittie <smcv@debian.org>, 510644@bugs.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Sun, 4 Jan 2009 14:27:33 +0100

On Sun, Jan 04, 2009 at 01:29:44AM +0000, Simon McVittie wrote:
> Package: bluez-utils
> Version: 3.36-2
> Severity: serious
> Justification: blocker for #503532 (CVE-2008-4311) and far-fetched security hole
> Tags: fixed-upstream
> User: pkg-utopia-maintainers@lists.alioth.debian.org
> Usertags: CVE-2008-4311
> 
> bluez-utils installs a D-Bus system policy file intending to allow users
> at the console to send BlueZ messages to hcid. However, it actually
> allows users at the console to send messages to the object path '/' on
> any service, slightly subverting access control for those other services.

Agreed.

> 
> Furthermore, it might be insufficient to allow everything that hcid intends to
> allow; messages used to be allowed accidentally by a dbus-daemon bug, but
> with the dbus-daemon changes targeted for lenny, they will be denied
> unless explicitly allowed.
> 
> <http://git.kernel.org/?p=bluetooth/bluez.git;a=history;f=src/bluetooth.conf;h=c0476237;hb=fb333f1c>
> shows the recent history of this file - the latest version,
> <http://git.kernel.org/?p=bluetooth/bluez.git;a=blob;f=src/bluetooth.conf;hb=06637b08>,
> appears to be appropriate.

I have tried with the experimental version of dbus and the said bluetooth.conf
file and it doesn't seem to work, though I'm investigating.

thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

Gretchen: Donnie Darko? What the hell kind of name is that? It's like
          some sort of superhero or something.
  Donnie: What makes you think I'm not?
-- from Donnie Darko (2001)

Message #17 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Filippo Giunchedi <filippo@debian.org>

Cc: 510644@bugs.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Sun, 4 Jan 2009 20:36:57 +0000

[Message part 1 (text/plain, inline)]

tags 510644 - fixed-upstream
thanks

On Sun, 04 Jan 2009 at 14:27:33 +0100, Filippo Giunchedi wrote:
> I have tried with the experimental version of dbus and the said bluetooth.conf
> file and it doesn't seem to work, though I'm investigating.

Thanks. You might get better debug logging with my "release candidate"
version of dbus from http://people.debian.org/~smcv/dbus-cve-2008-4311/ -
this is what we want to push into lenny once hal, system-tools-backends,
policykit and bluez-utils are fixed.

Regards,
    Simon

[signature.asc (application/pgp-signature, inline)]

Message #24 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Filippo Giunchedi <filippo@debian.org>

To: Simon McVittie <smcv@debian.org>, 510644@bugs.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Mon, 5 Jan 2009 20:32:09 +0100

On Sun, Jan 04, 2009 at 08:36:57PM +0000, Simon McVittie wrote:
> tags 510644 - fixed-upstream
> thanks
> 
> On Sun, 04 Jan 2009 at 14:27:33 +0100, Filippo Giunchedi wrote:
> > I have tried with the experimental version of dbus and the said bluetooth.conf
> > file and it doesn't seem to work, though I'm investigating.
> 
> Thanks. You might get better debug logging with my "release candidate"
> version of dbus from http://people.debian.org/~smcv/dbus-cve-2008-4311/ -
> this is what we want to push into lenny once hal, system-tools-backends,
> policykit and bluez-utils are fixed.

It seems like upstream config was missing the reply part, I got this:

  <policy user="root">
    <allow own="org.bluez"/>
    <allow send_destination="org.bluez"/>
    <allow send_interface="org.bluez.Agent"/>
  </policy>

  <policy at_console="true">
    <allow receive_sender="org.bluez"/>
  </policy>

  <policy context="default">
    <allow send_destination="org.bluez"/>
  </policy>

and seems to work, will upload to unstable shortly.

filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

Odium turbae sanabit solitudo, taedium solitudinis turba.
Solitude will cure our hatred of the crowd,
the crowd will cure our disgust with solitude.
-- Seneca, De Tranquillitate Animi

Message #29 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <simon.mcvittie@collabora.co.uk>

To: 510644@bugs.debian.org

Cc: dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: Debian Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Mon, 5 Jan 2009 20:32:58 +0000

[Message part 1 (text/plain, inline)]

Cross-posting to D-Bus upstream and pkg-utopia Debian maintainers in an
attempt to get some clarification. We should take this to BlueZ upstream
too, once we've worked out what it is we should be recommending...

On Mon, 05 Jan 2009 at 20:32:09 +0100, Filippo Giunchedi wrote:
> It seems like upstream config was missing the reply part, I got this:
> 
>   <policy user="root">
>     <allow own="org.bluez"/>
>     <allow send_destination="org.bluez"/>

Looks fine so far...

>     <allow send_interface="org.bluez.Agent"/>

That will work but is not ideal; D-Bus upstream opinion seems to be that
a bare "send_interface" without a corresponding send_destination is
almost always an error (because it matches the corresponding interface on
completely unrelated processes). Do Agent implementations have a well-known
service name you can use?

Failing that, maybe you could at least match on object path as well as
on interface?

(Sorry, I didn't spot that upstream had done this. This is
<http://bugs.freedesktop.org/show_bug.cgi?id=18961>.
<deny> with only a send_interface is certainly harmful; <allow> like
this might be OK?)

>   <policy at_console="true">
>     <allow receive_sender="org.bluez"/>
>   </policy>

I think this is meant to be unnecessary in dbus 1.2.8 (and 1.2.1-5 in
Debian, which has the patches backported).

>   <policy context="default">
>     <allow send_destination="org.bluez"/>
>   </policy>

Is it safe for every local user to be able to call methods on the org.bluez
service? If not, this needs fixing. To match the behaviour of the lenny
bluetooth.conf it should be in <policy at_console="true">, but I don't
think that ever actually worked on Debian systems unless you have
libpam-foreground or ConsoleKit (and possibly not even then).

Debian packages usually have a dual at_console/group-based policy for device
accesses like this (e.g. members of powerdev and netdev can use various
interfaces on hal even if they are not at_console), by duplicating the
permissions of the at_console <policy> into a separate group policy. See
NetworkManager's configuration in Debian, for instance.

> and seems to work, will upload to unstable shortly.

OK, but please don't request an unblock from the release team until we've had
some feedback from D-Bus upstream; the services whose rules don't work
seem to be the complicated ones :-(

Thanks,
    Simon

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Filippo Giunchedi <filippo@debian.org>

To: Simon McVittie <simon.mcvittie@collabora.co.uk>, 510644@bugs.debian.org

Cc: dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: Debian Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Mon, 5 Jan 2009 23:32:50 +0100

On Mon, Jan 05, 2009 at 08:32:58PM +0000, Simon McVittie wrote:
> >   <policy user="root">
> >     <allow own="org.bluez"/>
> >     <allow send_destination="org.bluez"/>
> 
> Looks fine so far...
> 
> >     <allow send_interface="org.bluez.Agent"/>
> 
> That will work but is not ideal; D-Bus upstream opinion seems to be that
> a bare "send_interface" without a corresponding send_destination is
> almost always an error (because it matches the corresponding interface on
> completely unrelated processes). Do Agent implementations have a well-known
> service name you can use?
> 
> Failing that, maybe you could at least match on object path as well as
> on interface?

Unfortunately they don't a well known service name nor object path, agents are
user-registered

> 
> (Sorry, I didn't spot that upstream had done this. This is
> <http://bugs.freedesktop.org/show_bug.cgi?id=18961>.
> <deny> with only a send_interface is certainly harmful; <allow> like
> this might be OK?)

That is <allow send_interface="org.bluez.Agent"/> ?

I think so, yes. (note that upstream 4.x uses org.bluez.Agent while 3.x (which
is debian) uses org.bluez.PasskeyAgent and org.bluez.AuthorizationAgent but they
basically the same)

> 
> >   <policy at_console="true">
> >     <allow receive_sender="org.bluez"/>
> >   </policy>
> 
> I think this is meant to be unnecessary in dbus 1.2.8 (and 1.2.1-5 in
> Debian, which has the patches backported).

I just retried and indeed it seems to work without, thanks for spotting this.

> 
> >   <policy context="default">
> >     <allow send_destination="org.bluez"/>
> >   </policy>
> 
> Is it safe for every local user to be able to call methods on the org.bluez
> service? If not, this needs fixing. To match the behaviour of the lenny
> bluetooth.conf it should be in <policy at_console="true">, but I don't
> think that ever actually worked on Debian systems unless you have
> libpam-foreground or ConsoleKit (and possibly not even then).

Mh, no it wouldn't be safe indeed.

> 
> Debian packages usually have a dual at_console/group-based policy for device
> accesses like this (e.g. members of powerdev and netdev can use various
> interfaces on hal even if they are not at_console), by duplicating the
> permissions of the at_console <policy> into a separate group policy. See
> NetworkManager's configuration in Debian, for instance.

Okay, given that using AF_BLUETOOTH sockets requires CAP_NET_ADMIN for some
ioctls I'd go for netdev group, makes sense?

thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

Either this man is dead or my watch has stopped.
-- Groucho Marx

Message #39 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <simon.mcvittie@collabora.co.uk>

To: Filippo Giunchedi <filippo@debian.org>, 510644@bugs.debian.org, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 19:17:35 +0000

[Message part 1 (text/plain, inline)]

On Mon, 05 Jan 2009 at 23:32:50 +0100, Filippo Giunchedi wrote:
> On Mon, Jan 05, 2009 at 08:32:58PM +0000, Simon McVittie wrote:
> > >     <allow send_interface="org.bluez.Agent"/>
> > 
> > That will work but is not ideal; D-Bus upstream opinion seems to be that
> > a bare "send_interface" without a corresponding send_destination is
> > almost always an error (because it matches the corresponding interface on
> > completely unrelated processes). Do Agent implementations have a well-known
> > service name you can use?
> > 
> > Failing that, maybe you could at least match on object path as well as
> > on interface?
> 
> Unfortunately they don't a well known service name nor object path, agents are
> user-registered

Never mind. We have a lot of these rules in the archive anyway
(http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-utopia-maintainers@lists.alioth.debian.org&tag=fdo-18961)
and as far as I can tell it's not a release-critical bug, particularly
as an <allow> rule... so leave it like that unless D-Bus upstream can
explain something better.

> > Debian packages usually have a dual at_console/group-based policy for device
> > accesses like this (e.g. members of powerdev and netdev can use various
> > interfaces on hal even if they are not at_console), by duplicating the
> > permissions of the at_console <policy> into a separate group policy. See
> > NetworkManager's configuration in Debian, for instance.
> 
> Okay, given that using AF_BLUETOOTH sockets requires CAP_NET_ADMIN for some
> ioctls I'd go for netdev group, makes sense?

netdev sounds the most appropriate, yes. avahi-daemon has some suitable
postinst snippets to create the group if necessary, before telling D-Bus
to reload:

case "$1" in
  configure)

    ...

    # Add the netdev group unless it's already there
    if ! getent group netdev >/dev/null; then
      addgroup --quiet --system netdev || true
    fi

    ...

    # Ask the bus to reload the config file
    if [ -x "/etc/init.d/dbus" ]; then
      invoke-rc.d dbus force-reload || true
    fi
  ;;

Apparently at_console works (or at least, can be made to work) if you have
ConsoleKit installed, so you should have two <policy> sections, one for
at_console and one for netdev, containing the same <allow> rules.

Please go ahead with the unstable upload, but also attach the resulting
bluetooth.conf to this bug so I can review it.

Thanks,
    Simon

[signature.asc (application/pgp-signature, inline)]

Message #44 received at 510644@bugs.debian.org (full text, mbox, reply):

From: "Colin Walters" <walters@verbum.org>

To: "Simon McVittie" <simon.mcvittie@collabora.co.uk>

Cc: "Filippo Giunchedi" <filippo@debian.org>, 510644@bugs.debian.org, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 14:45:37 -0500

On Wed, Jan 7, 2009 at 2:17 PM, Simon McVittie
<simon.mcvittie@collabora.co.uk> wrote:
>
>> Unfortunately they don't a well known service name nor object path, agents are
>> user-registered
>
> Never mind. We have a lot of these rules in the archive anyway
> (http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-utopia-maintainers@lists.alioth.debian.org&tag=fdo-18961)
> and as far as I can tell it's not a release-critical bug, particularly
> as an <allow> rule... so leave it like that unless D-Bus upstream can
> explain something better.

What's the scenario exactly?  I had thought the <allow
send_destination="org.bluez"/> was sufficient for bluetooth; is that
not the case?

Message #49 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <simon.mcvittie@collabora.co.uk>

To: Colin Walters <walters@verbum.org>

Cc: Filippo Giunchedi <filippo@debian.org>, 510644@bugs.debian.org, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 20:09:19 +0000

[Message part 1 (text/plain, inline)]

On Wed, 07 Jan 2009 at 14:45:37 -0500, Colin Walters wrote:
> On Wed, Jan 7, 2009 at 2:17 PM, Simon McVittie
> <simon.mcvittie@collabora.co.uk> wrote:
> >
> >> Unfortunately they don't a well known service name nor object path, agents are
> >> user-registered
> >
> > Never mind. We have a lot of these rules in the archive anyway
> > (http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-utopia-maintainers@lists.alioth.debian.org&tag=fdo-18961)
> > and as far as I can tell it's not a release-critical bug, particularly
> > as an <allow> rule... so leave it like that unless D-Bus upstream can
> > explain something better.
> 
> What's the scenario exactly?  I had thought the <allow
> send_destination="org.bluez"/> was sufficient for bluetooth; is that
> not the case?

As far as I can tell, BlueZ agents work like this:

* the agent (a UI process run by a user) calls a method on the hci daemon (run
  by root) and passes in its unique name and its (arbitrary) object path
* later, the hci daemon calls a method on the agent

so the only thing that can be relied on is that when the hci daemon calls
the method, it's on the org.bluez.Agent interface!

Mitigating factor: the hci daemon runs as root, so only root needs
permission to call arbitrary methods from the Agent interface on
arbitrary processes at arbitrary object paths, and root can ptrace or
impersonate hcid (or indeed dbus-daemon) anyway.

    Simon

[signature.asc (application/pgp-signature, inline)]

Message #54 received at 510644@bugs.debian.org (full text, mbox, reply):

From: "Colin Walters" <walters@verbum.org>

To: "Simon McVittie" <simon.mcvittie@collabora.co.uk>

Cc: "Filippo Giunchedi" <filippo@debian.org>, 510644@bugs.debian.org, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 15:26:31 -0500

On Wed, Jan 7, 2009 at 3:09 PM, Simon McVittie
<simon.mcvittie@collabora.co.uk> wrote:
>
> As far as I can tell, BlueZ agents work like this:
>
> * the agent (a UI process run by a user) calls a method on the hci daemon (run
>  by root) and passes in its unique name and its (arbitrary) object path
> * later, the hci daemon calls a method on the agent
>
> so the only thing that can be relied on is that when the hci daemon calls
> the method, it's on the org.bluez.Agent interface!

Urf.  Can we just change this to use signals?  Signals can be sent to
a particular destination only (I'm pretty sure).

> Mitigating factor: the hci daemon runs as root, so only root needs
> permission to call arbitrary methods from the Agent interface on
> arbitrary processes at arbitrary object paths, and root can ptrace or
> impersonate hcid (or indeed dbus-daemon) anyway.

In the absence of extended security systems like SELinux, yes.

Message #59 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Filippo Giunchedi <filippo@debian.org>

To: Simon McVittie <simon.mcvittie@collabora.co.uk>

Cc: 510644@bugs.debian.org, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 22:55:56 +0100

[Message part 1 (text/plain, inline)]

On Wed, Jan 07, 2009 at 07:17:35PM +0000, Simon McVittie wrote:
> On Mon, 05 Jan 2009 at 23:32:50 +0100, Filippo Giunchedi wrote:
> > On Mon, Jan 05, 2009 at 08:32:58PM +0000, Simon McVittie wrote:
> > > >     <allow send_interface="org.bluez.Agent"/>
> > > 
> > > That will work but is not ideal; D-Bus upstream opinion seems to be that
> > > a bare "send_interface" without a corresponding send_destination is
> > > almost always an error (because it matches the corresponding interface on
> > > completely unrelated processes). Do Agent implementations have a well-known
> > > service name you can use?
> > > 
> > > Failing that, maybe you could at least match on object path as well as
> > > on interface?
> > 
> > Unfortunately they don't a well known service name nor object path, agents are
> > user-registered
> 
> Never mind. We have a lot of these rules in the archive anyway
> (http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-utopia-maintainers@lists.alioth.debian.org&tag=fdo-18961)
> and as far as I can tell it's not a release-critical bug, particularly
> as an <allow> rule... so leave it like that unless D-Bus upstream can
> explain something better.
> 
> > > Debian packages usually have a dual at_console/group-based policy for device
> > > accesses like this (e.g. members of powerdev and netdev can use various
> > > interfaces on hal even if they are not at_console), by duplicating the
> > > permissions of the at_console <policy> into a separate group policy. See
> > > NetworkManager's configuration in Debian, for instance.
> > 
> > Okay, given that using AF_BLUETOOTH sockets requires CAP_NET_ADMIN for some
> > ioctls I'd go for netdev group, makes sense?
> 
> netdev sounds the most appropriate, yes. avahi-daemon has some suitable
> postinst snippets to create the group if necessary, before telling D-Bus
> to reload:

okay, thanks, I'll put a note in NEWS.Debian too

[...]

> Apparently at_console works (or at least, can be made to work) if you have
> ConsoleKit installed, so you should have two <policy> sections, one for
> at_console and one for netdev, containing the same <allow> rules.
> 
> Please go ahead with the unstable upload, but also attach the resulting
> bluetooth.conf to this bug so I can review it.

attached, note that I used AuthorizationAgent and PasskeyAgent interfaces
because that's what bluez 3.x uses while 4.x has Agent interface

filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

How do you feel about women's rights? I like either side of them.
-- Groucho Marx

[bluetooth.conf (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #64 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <simon.mcvittie@collabora.co.uk>

To: 510644@bugs.debian.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 23:02:35 +0000

[Message part 1 (text/plain, inline)]

On Wed, 07 Jan 2009 at 22:55:56 +0100, Filippo Giunchedi wrote:
> On Wed, Jan 07, 2009 at 07:17:35PM +0000, Simon McVittie wrote:
> > Please go ahead with the unstable upload, but also attach the resulting
> > bluetooth.conf to this bug so I can review it.
> 
> attached, note that I used AuthorizationAgent and PasskeyAgent interfaces
> because that's what bluez 3.x uses while 4.x has Agent interface

Looks good to me - please ask for a freeze exception on -release too, as
we probably won't upload dbus to unstable until bluez-utils and other
such packages migrate.

Thanks,
    Simon

[signature.asc (application/pgp-signature, inline)]

Message #69 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <simon.mcvittie@collabora.co.uk>

To: Colin Walters <walters@verbum.org>

Cc: Filippo Giunchedi <filippo@debian.org>, 510644@bugs.debian.org, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 23:25:00 +0000

[Message part 1 (text/plain, inline)]

On Wed, 07 Jan 2009 at 15:26:31 -0500, Colin Walters wrote:
> On Wed, Jan 7, 2009 at 3:09 PM, Simon McVittie
> <simon.mcvittie@collabora.co.uk> wrote:
> >
> > As far as I can tell, BlueZ agents work like this:
> 
> Urf.  Can we just change this to use signals?  Signals can be sent to
> a particular destination only (I'm pretty sure).

As a long-term solution, that'd probably be a good thing to suggest (I've
avoided cross-posting to BlueZ upstream, until we have a consistent
recommendation to give them!)

As a solution for the current release of BlueZ, assuming that rethinking
the Agent API completely is not an option, does the proposed policy at
<http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=59;filename=bluetooth.conf;att=1;bug=510644>
need to be vetoed? It seems to me to be non-ideal, but the best we can get
right now; but I still don't fully understand the D-Bus policy language (I'm
not convinced anyone does...) so I could be wrong.

(It is intentional that the netdev group always have privileges equal to an
at_console user; that particular change is an odd Debianism caused by
ConsoleKit/pam_console/etc. not being a hard dependency.)

Thanks,
    Simon

[signature.asc (application/pgp-signature, inline)]

Message #74 received at 510644@bugs.debian.org (full text, mbox, reply):

From: "Colin Walters" <walters@verbum.org>

To: "Simon McVittie" <simon.mcvittie@collabora.co.uk>

Cc: "Filippo Giunchedi" <filippo@debian.org>, 510644@bugs.debian.org, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 18:40:20 -0500

On Wed, Jan 7, 2009 at 6:25 PM, Simon McVittie
<simon.mcvittie@collabora.co.uk> wrote:
>
> As a solution for the current release of BlueZ, assuming that rethinking
> the Agent API completely is not an option, does the proposed policy at
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=59;filename=bluetooth.conf;att=1;bug=510644>
> need to be vetoed? It seems to me to be non-ideal, but the best we can get
> right now; but I still don't fully understand the D-Bus policy language (I'm
> not convinced anyone does...) so I could be wrong.

I think that policy is "ok"; but not ideal as you say.  It seems
extremely unlikely to me that it would introduce any security problem.
 Regardless hopefully bluez can move to signals over a transition
period.

Message #79 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Marcel Holtmann <marcel@holtmann.org>

To: Colin Walters <walters@verbum.org>

Cc: Simon McVittie <simon.mcvittie@collabora.co.uk>, 510644@bugs.debian.org, Filippo Giunchedi <filippo@debian.org>, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Thu, 08 Jan 2009 00:41:59 +0100

Hi Colin,

> > As far as I can tell, BlueZ agents work like this:
> >
> > * the agent (a UI process run by a user) calls a method on the hci daemon (run
> >  by root) and passes in its unique name and its (arbitrary) object path
> > * later, the hci daemon calls a method on the agent
> >
> > so the only thing that can be relied on is that when the hci daemon calls
> > the method, it's on the org.bluez.Agent interface!
> 
> Urf.  Can we just change this to use signals?  Signals can be sent to
> a particular destination only (I'm pretty sure).

that is exactly how it works and we can't use signal. Even directed
signal are not working since the method call into the agent has to
return the result or an error.

What problem do you guys actually have with this? The agent inside
bluez-gnome is verifying that the method comes from the daemon it
registers its agent with and thus there is not even a security issue
here with trying to send arbitrary method calls to the UI.

Regards

Marcel

Message #84 received at 510644@bugs.debian.org (full text, mbox, reply):

From: "Colin Walters" <walters@verbum.org>

To: "Marcel Holtmann" <marcel@holtmann.org>

Cc: "Simon McVittie" <simon.mcvittie@collabora.co.uk>, 510644@bugs.debian.org, "Filippo Giunchedi" <filippo@debian.org>, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Wed, 7 Jan 2009 19:19:43 -0500

On Wed, Jan 7, 2009 at 6:41 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> that is exactly how it works and we can't use signal. Even directed
> signal are not working since the method call into the agent has to
> return the result or an error.
>
> What problem do you guys actually have with this? The agent inside
> bluez-gnome is verifying that the method comes from the daemon it
> registers its agent with and thus there is not even a security issue
> here with trying to send arbitrary method calls to the UI.

I talked with davidz about this on IRC in a bit more high bandwidth
mode; he's doing something similar with PolicyKit.  I think if the
rule is of the form:

<allow send_interface="org.bluez.Agent" send_path="/org/bluez/Agent"/>

that's probably fine.  It does allow any process to send any message
with that interface and path to any other, but we're in a similar
situation with signals anyways right now.  I wouldn't call it a
problem even if it's just an <allow send_interface>, but ideally we
don't have many of these since they're not as strong as <allow
send_destination>.

Message #89 received at 510644@bugs.debian.org (full text, mbox, reply):

From: Marcel Holtmann <marcel@holtmann.org>

To: Colin Walters <walters@verbum.org>

Cc: Simon McVittie <simon.mcvittie@collabora.co.uk>, 510644@bugs.debian.org, Filippo Giunchedi <filippo@debian.org>, dbus@lists.freedesktop.org, pkg-utopia-maintainers@lists.alioth.debian.org

Subject: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

Date: Thu, 08 Jan 2009 16:00:53 +0100

Hi Colin,

> > that is exactly how it works and we can't use signal. Even directed
> > signal are not working since the method call into the agent has to
> > return the result or an error.
> >
> > What problem do you guys actually have with this? The agent inside
> > bluez-gnome is verifying that the method comes from the daemon it
> > registers its agent with and thus there is not even a security issue
> > here with trying to send arbitrary method calls to the UI.
> 
> I talked with davidz about this on IRC in a bit more high bandwidth
> mode; he's doing something similar with PolicyKit.  I think if the
> rule is of the form:
> 
> <allow send_interface="org.bluez.Agent" send_path="/org/bluez/Agent"/>
> 
> that's probably fine.  It does allow any process to send any message
> with that interface and path to any other, but we're in a similar
> situation with signals anyways right now.  I wouldn't call it a
> problem even if it's just an <allow send_interface>, but ideally we
> don't have many of these since they're not as strong as <allow
> send_destination>.

the path where the Bluetooth agent lives can be freely chosen by the
agent. We are not restricting it to any path. This is needed since in
some cases an application might wanna register two agents. The BlueZ
agents are kinda stackable. We have a default one for normal requests
that can come in any time. And then transaction specific ones when we do
expect a pairing or authorization request. This design is on purpose to
allow the UI to present or overwrite these requests and handle them as
it fits best in that situation.

So what is your security concern here? Only the root user is to send
these information anyway. And once you are root, you can do whatever you
want. If you don't like the D-Bus policy, you just edit that file and
change it. I really don't get what you are trying to protect here.

And keep in mind that the client/agent has to protect itself and
bluez-gnome is doing this by verifying the sender of the request.

Regards

Marcel

Message #94 received at 510644-close@bugs.debian.org (full text, mbox, reply):

From: Filippo Giunchedi <filippo@debian.org>

To: 510644-close@bugs.debian.org

Subject: Bug#510644: fixed in bluez-utils 3.36-3

Date: Thu, 08 Jan 2009 18:02:04 +0000

Source: bluez-utils
Source-Version: 3.36-3

We believe that the bug you reported is fixed in the latest version of
bluez-utils, which is due to be installed in the Debian FTP archive:

bluetooth_3.36-3_all.deb
  to pool/main/b/bluez-utils/bluetooth_3.36-3_all.deb
bluez-audio_3.36-3_amd64.deb
  to pool/main/b/bluez-utils/bluez-audio_3.36-3_amd64.deb
bluez-cups_3.36-3_amd64.deb
  to pool/main/b/bluez-utils/bluez-cups_3.36-3_amd64.deb
bluez-pcmcia-support_3.36-3_amd64.deb
  to pool/main/b/bluez-utils/bluez-pcmcia-support_3.36-3_amd64.deb
bluez-utils_3.36-3.diff.gz
  to pool/main/b/bluez-utils/bluez-utils_3.36-3.diff.gz
bluez-utils_3.36-3.dsc
  to pool/main/b/bluez-utils/bluez-utils_3.36-3.dsc
bluez-utils_3.36-3_amd64.deb
  to pool/main/b/bluez-utils/bluez-utils_3.36-3_amd64.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 510644@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Filippo Giunchedi <filippo@debian.org> (supplier of updated bluez-utils package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 08 Jan 2009 18:42:24 +0100
Source: bluez-utils
Binary: bluez-utils bluez-pcmcia-support bluez-cups bluez-audio bluetooth
Architecture: source all amd64
Version: 3.36-3
Distribution: unstable
Urgency: high
Maintainer: Debian Bluetooth Maintainers <pkg-bluetooth-maintainers@lists.alioth.debian.org>
Changed-By: Filippo Giunchedi <filippo@debian.org>
Description: 
 bluetooth  - Bluetooth stack utilities
 bluez-audio - Bluetooth audio support
 bluez-cups - Bluetooth printer driver for CUPS
 bluez-pcmcia-support - PCMCIA support files for BlueZ 2.0 Bluetooth tools
 bluez-utils - Bluetooth tools and daemons
Closes: 510644
Changes: 
 bluez-utils (3.36-3) unstable; urgency=high
 .
   * Ship a new bluetooth.conf fixing dbus permissions RC bug (Closes: #510644)
     - As a result of this, now users of netdev group are able to communicate
       with hcid via dbus
     - Add netdev group in postinst if not present
Checksums-Sha1: 
 f29ae3e81a8bef2048104a01754e8790793095e1 1627 bluez-utils_3.36-3.dsc
 905d191c0a07a5651a19f18f5fd73c85ca5ddb49 22689 bluez-utils_3.36-3.diff.gz
 693d8b9405cea516b239f9166a873c51a3dfa5d6 22738 bluetooth_3.36-3_all.deb
 66a917112073e32d6b4dafb2447154b84ef6910a 381808 bluez-utils_3.36-3_amd64.deb
 e81b3e27fb0618bfa82077704e3319e0adb52e5f 24376 bluez-pcmcia-support_3.36-3_amd64.deb
 69306846062160c2f1069cf128dec630b088e99f 40246 bluez-cups_3.36-3_amd64.deb
 f4d2394521aec325fffd3e7206c9d796e316cd74 137900 bluez-audio_3.36-3_amd64.deb
Checksums-Sha256: 
 577b00f560dfc21eec75f9ae14262a7c23e4866f726cb0136506d099c2743297 1627 bluez-utils_3.36-3.dsc
 888bcd1192f4ed0ac288da565ac883a9fc517085d0ab831bb2ff6a13ee86fe7d 22689 bluez-utils_3.36-3.diff.gz
 09bfe57e5fa043f20d57601a612a50c5470ee32b10113fbf574e14ad83b82619 22738 bluetooth_3.36-3_all.deb
 101774d4d5f320879da61c6fff682dca4ea7f8449249458bf0e5732ba64fa15f 381808 bluez-utils_3.36-3_amd64.deb
 512076ca207ef9ce9879c10ca3d2954a5adc531ffad7f9ac02c1c110581448a6 24376 bluez-pcmcia-support_3.36-3_amd64.deb
 b291d1adb5b4002bef0cd75ddd892b54623ec6a980e5adcd18c64730e203ea2f 40246 bluez-cups_3.36-3_amd64.deb
 0798b9702645dc3b6731de46bac67463d477a0ebf1c0c70ab75a0e5bba06454a 137900 bluez-audio_3.36-3_amd64.deb
Files: 
 b84c8eda10912efb981a0af6c1423425 1627 admin optional bluez-utils_3.36-3.dsc
 c5c7753f98fd3712134b09da16eaa309 22689 admin optional bluez-utils_3.36-3.diff.gz
 18285fa968645e3c084c4121e64bd72f 22738 admin optional bluetooth_3.36-3_all.deb
 0b80c9322115b9a15db6cae0e305ddac 381808 admin optional bluez-utils_3.36-3_amd64.deb
 e6e395d058ba48b73a0c817841eca248 24376 admin extra bluez-pcmcia-support_3.36-3_amd64.deb
 bdcfd08150c7f19525423b908b271a8b 40246 admin optional bluez-cups_3.36-3_amd64.deb
 6b3e3cdf26b1d40f8c91f4060d1ef08d 137900 admin optional bluez-audio_3.36-3_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklmPOQACgkQABzeamt51AEg4wCfSaohAgr9ymxqMvVkLh3DSIuu
MPcAoJcT9th3j8jzmNhp5IKO2EdajZjG
=eb+9
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.