BlueZ configuration file/security question

[Claudio Takahasi]

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"/>
>   </policy>
>   <!-- 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"/>
>   </policy>
>
> 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.
>
> Havoc
>

Hi guys,

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.

BR,
Claudio.