[apparmor] dbus/pair address rule encoding

[Jamie Strandboge]

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>,

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=...,
}

-- 
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/f3508460/attachment.pgp>