On 05/09/2013 02:13 PM, Tyler Hicks wrote: > On 2013-05-09 14:04:20, 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. :) > > I agree that if you think of it in terms of 'peer', it doesn't make > sense. > > For the arrow to make sense, we'd need to think of the right side of the > arrow as the destination of the message. > > Take this rule for example: > > dbus bus=session -> name=com.example.service path=/com/example/service > interface=com.example.service receive, > > If we adjust our thinking a little it could mean, "a message that flows > FROM anywhere TO com.example.service can be received under the > current profile." > maybe its just me, I see this as getting into the old to/from problem that netdomain had
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor