[apparmor] dbus/pair address rule encoding

Seth Arnold seth.arnold at canonical.com
Thu May 9 21:04:20 UTC 2013


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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130509/6fff5a8c/attachment.pgp>


More information about the AppArmor mailing list