[apparmor] dbus/pair address rule encoding

[Tyler Hicks]

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