Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Mon, 05 Jan 2009 at 23:32:50 +0100, Filippo Giunchedi wrote: On Mon, Jan 05, 2009 at 08:32:58PM +, 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-maintain...@lists.alioth.debian.orgtag=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 Description: Digital signature
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Wed, Jan 7, 2009 at 2:17 PM, Simon McVittie simon.mcvit...@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-maintain...@lists.alioth.debian.orgtag=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? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
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.mcvit...@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-maintain...@lists.alioth.debian.orgtag=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 Description: Digital signature
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Wed, Jan 7, 2009 at 3:09 PM, Simon McVittie simon.mcvit...@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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Wed, Jan 07, 2009 at 07:17:35PM +, 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 +, 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-maintain...@lists.alioth.debian.orgtag=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 !-- This configuration file specifies the required security policies for Bluetooth core daemon to work. -- !DOCTYPE busconfig PUBLIC -//freedesktop//DTD D-BUS Bus Configuration 1.0//EN http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd; busconfig !-- ../system.conf have denied everything, so we just punch some holes -- policy user=root allow own=org.bluez/ allow send_destination=org.bluez/ allow send_interface=org.bluez.PasskeyAgent/ allow send_interface=org.bluez.AuthorizationAgent/ /policy policy at_console=true allow send_destination=org.bluez/ /policy policy group=netdev allow send_destination=org.bluez/ /policy /busconfig signature.asc Description: Digital signature
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Wed, 07 Jan 2009 at 22:55:56 +0100, Filippo Giunchedi wrote: On Wed, Jan 07, 2009 at 07:17:35PM +, 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 Description: Digital signature
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
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.mcvit...@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 Description: Digital signature
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Wed, Jan 7, 2009 at 6:25 PM, Simon McVittie simon.mcvit...@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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Wed, Jan 7, 2009 at 6:41 PM, Marcel Holtmann mar...@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. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Sun, Jan 04, 2009 at 08:36:57PM +, 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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: Debian Bug#510644: bluetooth.conf needs alterations for new D-Bus
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 Description: Digital signature
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: Debian Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Mon, Jan 05, 2009 at 08:32:58PM +, 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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
On Sun, Jan 04, 2009 at 01:29:44AM +, 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-maintain...@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) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
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 Description: Digital signature
Processed: Re: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus
Processing commands for cont...@bugs.debian.org: tags 510644 - fixed-upstream Bug#510644: bluetooth.conf needs alterations for new D-Bus Tags were: fixed-upstream Tags removed: fixed-upstream thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510644: bluetooth.conf needs alterations for new D-Bus
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-maintain...@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 Description: Digital signature
