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).
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
