[apparmor] dbus/pair address rule encoding

John Johansen john.johansen at canonical.com
Thu May 9 21:30:32 UTC 2013


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



More information about the AppArmor mailing list