BlueZ configuration file/security question
cktakahasi at gmail.com
Thu Nov 30 12:25:01 PST 2006
On 11/30/06, Havoc Pennington <hp at redhat.com> wrote:
> Claudio Takahasi wrote:
> > [Client]-------[hcid] -----> [ServiceAgent]
> > * Client: any application that wants use BlueZ services.
> > * hcid: main BlueZ daemon that manages local adapter setup tasks,
> > remote device discover, authetication, ...
> > * ServiceAgent: applications that wants provide a Bluetooth service.
> > eg: Audio, Network, Input, etc. ServiceAgents don't have a well-known
> > names. THE PATH AND THE INTERFACE ARE FREELY DEFINABLE.
> > MY QUESTION IS:
> > How we can AVOID send message directly to the ServiceAgent? (it is
> > possible send a message directly to the ServiceAgent using the "unique
> > connection name" and the right path)
> This is all on the system bus, right? (on the session bus there's no
> point worrying about security in this way)
> The issue is that to have a security policy that applies only to the
> ServiceAgents, you need some property unique to those agents. This could
> be the UNIX user or group, a well-known name, an object path or interface.
> "man dbus-daemon" has docs on the security policies. One thing the docs
> should mention but don't (someone please fix this!) is that a
> send_destination or receive_sender rule applies to *any queued owner* of
> the well-known name, not just the current primary owner of it.
> What this means is that you could have a well-known name
> org.bluez.ServiceAgent, and all service agents would ask to be in the
> queue for that name. Then the policy would be something like:
> <!-- deny sending to ServiceAgents or receiving from ServiceAgents -->
> <policy context="default">
> <deny send_destination="org.bluez.ServiceAgent"/>
> <deny receive_sender="org.bluez.ServiceAgent"/>
> <!-- allow some particular unix user to talk to service agents -->
> <policy user="bluezuser">
> <allow send_destination="org.bluez.ServiceAgent"/>
> <allow receive_sender="org.bluez.ServiceAgent"/>
> I think that would work, though obviously it hinges on running hcid as a
> special user. Presumably you already have to do this in order to supply
> security policies for talking to hcid itself.
> Another thing you could do is just don't use the bus for ServiceAgents,
> i.e. have them connect to the hcid directly.
thanks!!! I think the last option of using peer to peer connection
fits better, because Marcel wants keep the service paths/interfaces
freely definable and without well-known names for ServiceAgents. So,
there isn't a string pattern to create policies. I will start
investigate the peer to peer approach.
More information about the dbus