[apparmor] dbus/pair address rule encoding

[John Johansen]

On 05/09/2013 01:45 PM, Tyler Hicks wrote:
> On 2013-05-09 13:35:11, John Johansen wrote:
>> On 05/09/2013 01:20 PM, Jamie Strandboge wrote:
>>> On 05/09/2013 02:41 PM, John Johansen wrote:
>>>>
>>>> Lets look at it as local (subject) address and remote/peer address
>>>>
>>>> profile subject {
>>>>
>>>>   dbus name=well.known.address acquire,
>>>>
>>>>   dbus name=well.known.address receive,  #subject can receive messages on this well.known.address
>>>>
>>>>   dbus -> name=a.peer.address send,      #subject can send to a peer/remote process using the well known address a.peer.address
>>>>
>>>>   dbus -> name=a.peer.address receive,   #subject can receive a message from a peer/remote process that sent from its a.peer.address
>>>>                                          # this case is unusual
>>>>
>>>> }
>>>>
>>>> note that send atomically gives permission to receive a reply, just not to receive arbitrary new messages
>>>>
>>>> the unusually case is the one that tyler pointed out as problematic, and I'm not sure it really is but I would like to get this right
>>>>
>>>
>>> This explanation makes things a lot more clear for me. Part of my
>>> problem was that I was trying to apply natural language to the rule, but
>>> your explanation is clear.
>>>
>>> That said, and speaking for myself only, I think I got tripped up
>>> because '->' suggests a direction. In most cases this works out ok, but
>>> in the unusual case:
>>> dbus -> name=a.peer.address receive,
>>>
>>> my brain was thinking that the '->' meant 'to' and therefore the subject
>>> was sending something to the remote address, but the syntax actually
>>> meant it was receiving something. We can document around this since it
>>
>> yes natural language is the problem
>> -> as to causes problems
>> -> as my peer over there works
>>
>> we debated word or symbols and nothing was great, but a symbol can be
>> more universal and not get buried in the syntax
>>   dbus name=foo.com peer name=foo.com iface=blah member=help,
>>
>> peer just gets lost
>>
>>> is the unusual case, but will this be so unusual with non-DBus rules
>>> that use the same syntax? Would using 'remote:' be any clearer? Eg:
>>>   dbus name=well.known.address acquire,
>>>   dbus name=well.known.address receive,
>>>   dbus remote: name=a.peer.address send,
>>>   dbus remote: name=a.peer.address receive,
>>>
>> it might, but again it seems to get lost like the peer example. There are
>> trade offs I am not wedded to any one syntax
>>
>>> Typing that out, it seems not because the specified access on the RHS of
>>> the peer is actually describing (based on your descriptions, above) what
>>> the subject can do, as opposed to what the peer can do, but my brain
>>> wants the RHS of the peer to correspond to the peer itself, since it is
>>> closer. I don't think there is a way to make that confusion go away by
>>> substituting '->' for something else.
>>>
>> nope it is specifying what the subject can do. It can send/receive from
>> that remote.
>>
>> The remote will have its own set of rules that specify what it can do.
>> When communication happens BOTH set of rules are checked, and the communication
>> is allowed only if BOTH allow it. That is neither subject dominates the other.
>>
>> eg.
>>
>> A {
>>    ipc -> B (send, receive),
>>    ipc -> C (send),
>> }
>>
>> B {
>>    ipc -> A (send, receive),
>>    ipc -> C (receive),
>> }
>>
>> C {
>>   ipc -> A (send),
>>   ipc -> B (send),
>> }
>>
>> A and B can talk freely
>>
>> A and C can not communicate
>>
>> B can receive messages from C
>>
>>
>>> I'm tempted to suggest another syntax, but not sure how it would impact
>>> the non-DBus applications of the syntax.
>>>
>> please suggest away, its important to get this right (though we are trying
>> to fit it in with existing syntax as best as possible).
> 
> 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 ]
> 
> Mentally, I've been making a strong connection between
> <DBUS LOCAL CONDITIONS> and the application that we're confining. But
> that's the wrong way to think about it. The arrow makes more sense if
> you think about it in terms of traffic flow.
> 
> 
> 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,
> 
> Thie first rule allows the application to connect to the session bus.
> 
> The second rule allows the application to own the well known bus name
> com.example.service.
> 
> 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.
> 
Alright this I find this confusing too, and it has certainly changed what
the arrow and various parts do from how I understood the current proposed
syntax (not that changing what was proposed is a bad thing because it
certainly has caused confusion). I also worry about this change in the
context of trying to be consistent with other forms of communication.

To be clear the example rule rewritten in the proposed syntax as I understood
it (that is causing problems and hence this whole discussion) would be

Application {
  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,
}

Notice the only change is rule 3, and its the removal of the ->
Notice this also highlights an error in the spec we originally had. In the case of receive it does make sense to allow for interface/member

of course I find this #3 confusing too if I think about it from the message
pov. The thing is with dbus name/interface/member all combine to form
and address and the payload we don't look at is the message.


the com.example.service is definitely the local address that the subject is
receiving the message on, not the remote address where it is coming from.

The rule needs to be authored from the subjects pov, and generically we want
to allow pairing of local and peer address

tyler in you proposed syntax how would you tie the local and peer address for
a given communication? I realize this isn't something that happens in dbus
currently but it could in other forms of communication

> If you wanted to confine an application that needs to call ExampleMethod, it's
> profile would look like this:
> 
>   dbus bus=session -> name=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus send,
>   dbus bus=session -> name=com.example.service path=/com/example/service interface=com.example.service member=ExampleMethod send,
> 
> The first rule allows the application to connect to the session bus.
> 
> The second rule allows the application to call the service's
> ExampleMethod (the method_return permission is implied).
> 
this matches up with what I understood of the proposed syntax