[apparmor] DBus rule syntax for subject and peer components

[John Johansen]

On 06/21/2013 07:07 AM, Steve Beattie wrote:
> On Thu, Jun 20, 2013 at 11:41:21AM -0700, Tyler Hicks wrote:
>> Proposals that were decisively approved through voting:
>>
>> * Proposal 3.1 - Change subj= to subject=
>> * Proposal 3.2 - Move the access to the front
> 
> Yay. (Also, retroactive +1 from me on both.)
> 
>> Unfortunately, the way that I laid out the proposals in the last email
>> did not result in clear decision on whether people preferred the
>> original Proposal 3's grouping like subject=() or Proposal 3.5's
>> subject {} style.
> 
> Really, seems like there's two orthogonal bits, whether to use '{}' or
> '()' as delimiters and whether to have an '=' between subject/peer and
> the delimiter.
> 
> I can see the argument against using '{}' as a delimiter due to
> confusion with alternation uses (from a human cognition perspective,
> not from a tool implementation perspective). So I lean towards using
> '()' as the delimiter. But it's a not a strong preference.
> 
> As to using '=' prefixing the delimited group, I've grown comfortable
> seeing it in the examples with it, but I don't have a strong
> preference, so maybe +0.1? :)
> 
>>   # Talks to system and session buses
>>   dbus (send receive) bus={system,session} peer=(name=org.freedesktop.DBus),
> 
> Shouldn't "(send receive)" be an alternation a la "{send, receive}"?
no its not an alternation, its a multi-valued set. That is it grants
send,
receive,
send and receive at the same time

an alternation would one of send or receive

> (Though it's an odd rule to begin with, stating that the screensaver
> can both send to the org.freedesktop.DBus name and receive messages
> sent to that name, assuming an acquire rule is also given to let it
> acquire the name.)
> 
well if acquire was specified it would apply to the local/subject address
not to the peer. Since the subject is missing that would mean it could
acquire any address

send and receive are a little weird in that for the subject address they
can be read as
  send_on and receive_on
and from the peer address
  send_to and receive_from

in this case since there is no subject address specified, there is no
pairing requirements being set. In fact I am not sure it will ever
make sense to have pairing requirements with dbus rules. Nor am I
entirely convinced at the moment that pairing is worth the cost for
other forms of ipc

In generally I think we want acquire or any permission that only
applies to a subject address to semantically be in a separate rule
that does not specify a peer address. This helps keep the meaning
of the rules clear. We can enforce this type of restriction with
a semantic check in the parser

> On Thu, Jun 20, 2013 at 03:30:12PM -0700, Seth Arnold wrote:
>> On Thu, Jun 20, 2013 at 11:41:21AM -0700, Tyler Hicks wrote:
>>> * Revised Proposal 3 - subject=() and peer=()
>>>
>>> dbus [acquire] [<bus>] [subject=(<subject>)],
>>> dbus [send | receive] [<bus>] [subject=(<subject>)] [peer=(<peer>)],
>>
>>
>>> * Revised Proposal 3.5 - subject {} and peer {}
>>>
>>> dbus [acquire] [<bus>] [subject {<subject>}],
>>> dbus [send | receive] [<bus>] [subject {<subject>}] [peer {<peer>}],
>>
>> I slightly prefer 3.5 to 3 -- the = just feels like more noise to me.
>>
>> Given that 3 looks like it is getting the consensus :) I'd like to cast
>> a vote _against_ the following token definitions:
>>
>> PEER		peer=(
>> SUBJECT		subject=(
>>
>> Those just seem wrong :) and I wanted to make sure that whatever is used
>> allows whitespace to separate keywords and operators.
> 
> Yes, I agree. We've tried hard at the parser level to be fairly
> whitespace agnostic to allow preferred organizational layouts.
> 
> For example, I would hope that the following layout would be accepted
> under format 3:
> 
>   # Sends messages on the system bus
>   dbus send   bus = system    peer = (
>   	name=org.freedesktop.ConsoleKit
> 	path=/org/freedesktop/ConsoleKit/Manager
> 	interface=org.freedesktop.ConsoleKit.Manager
>   ),
> 
yes it should be

> and format 3.5:
> 
>   # Sends messages on the system bus
>   dbus send   bus = system    peer {
> 	name=org.freedesktop.ConsoleKit
> 	path=/org/freedesktop/ConsoleKit/Manager
> 	interface=org.freedesktop.ConsoleKit.Manager
>   },
> 
> 
yep