[apparmor] dbus/pair address rule encoding

[John Johansen]

On 05/09/2013 02:12 PM, Jamie Strandboge wrote:
> On 05/09/2013 03:35 PM, 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.
>>
> 
> Ok, right, this is like any other rule where the access perms are at the
> far right of the rule.
> 
yes, there was an attempt to allow them to be at the start of the rule
at one point but people didn't like that either.

> I think '->' is such a strong delimiter that it both communicates
> direction and implies this (nonsensical) syntax is possible:
> dbus name=well.known.address receive -> name=a.peer.address send,
> 
yes I am definitely seeing '->' as the wrong choice for a separator

>> 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.
>>
> Noted. I think when describing this in the man page, we'll want to
> discuss this (I can help with that).
> 
>> 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
>>
> IIUC, A can send to C and C can send to A. Therefore the receive is
> implied in both of these such that if A sends to C, A gets C's response.
> In this manner, can't they actually communicate?
> 
Nope, receive is not implied, only the ability to receive a reply is implied
with the dbus rules.

  Thus C can not send to A, because while the send passes C's check. It
  fails the check that A does to see if it can receive the message.

  The same goes for the other direction

>> 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).
>>
> 
> Perhaps the problem is that the mixture of optional clauses in the
> syntax which makes the placement of access rules awkward. Ie, we always
> must have:
> 
>   dbus <access>,
> 
> but these are also valid (assuming '->' is part of <peer>):
>   dbus <subject> <access>,
>   dbus <peer> <access>,
>   dbus <subject> <peer> <access>,
> 
> Since <access> *always* applies to <subject>, maybe it makes sense to
> have it be next to it. Ie:
> 
>   dbus [<subject>] <access> [<peer>],
> 
> such that:
> 
> profile subject {
>   dbus name=well.known.address acquire,
>   dbus name=well.known.address receive,
>   dbus send -> name=a.peer.address,
>   dbus receive -> name=a.peer.address,
> 
>   # get as specific as you like:
>   dbus name=... interface=... (send, receive) -> name=... path=...,
> }
> 
that is a possibility, though it breaks with the "syntax" of having the
permission at the end of the rule. This is actually a case where the
permission at the start of the rule makes more sense, than at the tail.

(send, receive) dbus name=... interface=... -> name=... path=...,

of course I'd like to here seth and steve's input on that