[apparmor] dbus/pair address rule encoding

John Johansen john.johansen at canonical.com
Thu May 9 21:51:38 UTC 2013


On 05/09/2013 02:39 PM, Tyler Hicks wrote:
> 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. :)
> 
long ago there was a network extension to apparmor that did horrible
things. It would make kernel devs cry and shake out of shear terror.
It died on the vine because the hacks where unmaintainable, and
would result in the kernel community hunting you down and killing you
if you tried to submit it. :)

Anyways its syntax tried to take a message flow approach with natural
language and it ended up being confusing

it went something like
  tcp receive from blah,
  tcp send to blah,

  tcp send from blah to blah,
  tcp send,receive from blah to blah,

I don't remember the full syntax. But to/from would switch meaning based
on whether send or receive was used and it had another problem I failing
to remember.

that is not to say your proposed syntax does this but it is flipping
what I expect from -> and causing me to be confused.

that is -> means one thing on send and other on receive




More information about the AppArmor mailing list