[apparmor] dbus/pair address rule encoding

John Johansen john.johansen at canonical.com
Thu May 9 21:27:48 UTC 2013


On 05/09/2013 02:04 PM, Seth Arnold wrote:
> On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote:
>> I think that we're mostly ok. We just need to think about it a little
>> differently. Here's the current syntax:
>>
>> DBUS RULE = [ 'audit' ] [ 'deny' ] 'dbus' [ DBUS BUS ] [ ( DBUS LOCAL CONDITIONS | -> DBUS REMOTE CONDITIONS ) ]  [ DBUS ACCESS EXPRESSION ]
>>
> 
> [ ... ]
> 
>>
>> For example, to profile an application that acquires the well known name
>> com.example.service on the session bus and exports the ExampleMethod
>> method on the com.example.service interface, this would be what the dbus
>> portion of the service's profile looks like:
>>
>>   dbus bus=session -> name=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus send,
>>   dbus bus=session name=com.example.service acquire,
>>   dbus bus=session -> name=com.example.service path=/com/example/service interface=com.example.service member=ExampleMethod receive,
>>
> 
> [ ... ]
> 
>>
>> The third rule allows messages to be sent from *any* connection to the
>> service. Note that the even though com.example.service is owned by the
>> application that we're profiling, it's address is specified in the
>> <DBUS REMOTE CONDITIONS>. I think that's acceptable.
> 
> If the application acquired the interface and the application exports
> the method, why are those details placed on the 'peer' side of the
> arrow? I'm very confused here. :)
> 
Because we are mixing conflating things a bit, and need to be more
clear.

Lets say we have a service A. A acquires a well known address and
starts advertising its services on it.  A needs to be able to
receive and respond to messages from B an application.

A {
  dbus name=well.known.address acquire,
  dbus name=well.known.address iface=com.foo method=foo receive,
}

this says that A can acquire the address and then receive messages on that
address on a specific interface and method

receive implies it can reply so their is no need to have a send perm
here.

now for B

B {
  dbus -> name=well.known.address iface=com.foo method=foo send,
}

this lets B send a message (method call or signal) to be and receive the
reply. Both A and Bs rules get applied when a message is sent. B is sending
to a remote at a given addres, and A is receiving from a remote the
specified address.

Now I have glossed things over because A and B both need to be able
to send to dbus so they each need a send rule for that well known address
but I think throwing that in just confuses the conversation.

Now to pairing. Pairing allows you to control which local address a
message goes through to the remote address. This is akin to only allowing
network messages to be send or received from iface1 to/from address 10.1.xx.xx

In the pairing case you could have the full dbus address specified on both
sides. But this is confusing, because it smushing things together, because
with dbus you don't send from and iface or method

A {
  dbus name=A.address iface=com.foo method=foo -> name=B.address foo=com.bar method=bar (send, receive)

  #which rely means
  dbus name=A.address -> name=B.address foo.com.bar method=bar send,
  dbus name=A.address iface=com.foo method=foo -> name=B.address receive,
}





More information about the AppArmor mailing list