On 2013-05-09 14:30:32, John Johansen wrote: > 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
Mind explaining this a little more? I don't see netdomain in apparmor.d(5) and have no idea what that problem may have been. :) Tyler
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
