[apparmor] dbus/pair address rule encoding

[Jamie Strandboge]

On 05/09/2013 04: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.
> 
> 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,
> 
>> 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?
> 
>> 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>,
> 
Heh, I forgot, <access> itself is optional. Still, I think my point
stands-- having the access rules nearer the subject may be clearer.


-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130509/00ba78b2/attachment-0001.pgp>