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. :)
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
