[apparmor] dbus/pair address rule encoding

[John Johansen]

On 05/10/2013 07:45 AM, Jamie Strandboge wrote:
> On 05/10/2013 02:27 AM, John Johansen wrote:
>> On 05/09/2013 05:06 PM, Steve Beattie wrote:
>>> On Thu, May 09, 2013 at 02:41:19PM -0700, John Johansen wrote:
> 
>>> I don't mind Jamie's proposed syntax above, I don't really care for
>>> "(send, receive)" first, because having the dbus or network identifier
>>> first is a useful context granting mechanism.
>>>
>> So context granting for the parser or the human? I actually find the
>> permission first easier for some things, but I think that is just me
>>
> I think human parsing is vitally important. We need to have a clear and
> understandable syntax for policy writers so they get expected behavior
> and we need the same for policy auditing.
> 
>> I find I don't particularly like the permission embedded in the middle
>> of the rule, it makes it harder to find and associates it with the
>> local address, which isn't really true. It is for the pair.
>>
>> so what about
>>
>>   dbus (send, receive) name= ....,
>>
>> is that a better placement?
>>
> 
> This is actually what I thought you meant when you said access first. I
> am ok with this personally (but prefer my original to this).

well I wasn't clear and it could have been either

(send, receive) dbus ...
or
dbus (send, receive) ...

<< snip >>

>>  ie, dbus bus=session peer { name=a.peer.address } send,
>>
>> ( ) - used for a multi-valued set, but traditionally its been bare
>>
>>   profile (complain, attach_disconnected) { }
>>   dbus name=subjectA.service (send,receive),
>>
>> or prefixed with the value being set
>>   profile flags=(complain, attach_disconnected) { }
>>
>>   mount flags=(...),
>>
>>
>> would you be opposed to
>>
>>   dbus bus=session peer=(name=a.peer.address) send,
>>   net tcp addr=192.168.0.1 peer(addr=10.1.0.0/24 port=443) send,
>>
> 
> The 'dbus' rule uses 'peer=()' and the 'net' rule uses 'peer()'. I'm
> assuming this is not intentional?
> 
oops sorry, that was a mistake

> Regardless, mount also has:
> 
>   mount options=ro /dev/foo -> /mnt/,
>   mount options=(ro,atime),
>   mount options in (ro,atime),
> 
> I realize mount rule syntax is necessarily crazy and only point it out
> because while 'options=(ro,atime)' and 'options in (ro,atime)' are
> multi-valued sets, they convey quite different things.
> 
yes, however the = is the we want all of these and in is any combination
of. So = does work here, and we just don't allow in

> To exhaust all options, I'll mention we could do something with more in
> line with 'mount options in' and do:
> 
>   dbus bus=session peer is (name=a.peer.address) send,
>   net tcp addr=192.168.0.1 peer is (addr=10.1.0.0/24 port=443) send,
> 
> but this seems like a feeble attempt at language consistency, is
> cluttered and offers no benefit as a policy writer or auditer.
> 
yeah I would rather avoid that

> Another option that retains the spirit of the multi-valued set (note the
> commas within peer()) is:
> 
>   dbus peer (name=a.peer.address, interface=a.peer.interface) send,
>   net tcp addr=192.168.0.1 peer (addr=10.1.0.0/24, port=443) send,
> 
> but this is horribly inconsistent within the rule itself when the
> subject is specified (and no, I don't want commas for the subject). Eg:
> 
commas within the ( ) are optional and always have been.

>   dbus name=... path=... peer (name=..., interface=...) send,
> 
> 
> Furthermore, I don't think we can achieve perfect language consistency
> with the obvious grouping options: [], {}, and (). They are all used in
> our policy syntax and we already have some inconsistency with {}. It is
> used to group policy rules in a profile, for aare and for vars. Policy
> rules are grouped, but separated by commas which as noted above, doesn't
> work well. aare uses commas with {} and vars can be space-separated (eg,
> @{HOME}=@{HOMEDIRS}/*/ /root/). Perhaps since {} is already
> inconsistent, that is a case for it:
> 
yep, I just want to choose the least bad (which is likely different for
each of us)

>   dbus bus=session peer{name=a.peer.address} send,
>   net tcp addr=192.168.0.1 peer{addr=10.1.0.0/24 port=443} send,
> 
meh I'm not a fan of the word right next to {

> or:
> 
>   dbus bus=session peer={name=a.peer.address} send,
>   net tcp addr=192.168.0.1 peer={addr=10.1.0.0/24 port=443} send,
> 
I could live with this

> This doesn't look as clean and when reading it makes me start thinking
> about aare. I might point out we see '()' used in different ways in
> other languages. For example, C-based languages with loops and functions
> so I don't think people will despair if '()' isn't a multi-valued set in

yep

> our policy language. To me, Steve's original '()' is still the best:
> 
>   dbus bus=session peer(name=a.peer.address) send,
>   net tcp addr=192.168.0.1 peer(addr=10.1.0.0/24 port=443) send,
> 
Hrmmm I lean towards peer= but I can live with this as well

> (though I'm open to other grouping ideas).
>