[apparmor] dbus/pair address rule encoding

Fri May 10 15:24:25 UTC 2013

On 05/10/2013 09: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).
> 
>>> I had a thought that perhaps we should be explicit about which addresses
>>> are local to the subject and which are specific to a peer subject,
>>> rather than rely on contextual information of whether it's before or
>>> after a specific token. It could be something as simple as prefixing all
>>> the peer address identifiers with peer (or 'peer.' or 'peer_' or ...),
>>> so e.g. something like the following:
>>>
>>> profile SubjectA {
>>>
>>>   dbus bus=session name=this.subjects.service acquire,
>>>   dbus bus=session name=this.subjects.service receive,
>>>   dbus bus=session peername=a.peer.address send,
>>>   dbus bus=accessibility name=this.subjects.other.service acquire,
>>>   dbus bus=accessibility name=this.subjects.other.service peername=another.peer.address receive,
>>>   net tcp addr=192.168.0.1 peeraddr=10.1.0.0/24 peerport=443 send
>>>   net tcp addr=192.168.0.1 peerport=80 send
>>> }
>>>
>> so I don't care for prefixing peer
>>
> 
> Yeah, me either cause we end up with peername, peerpath, peermethod,
> and peerinterface which seems a bit verbose.
> 
>>> This way, the peer element doesn't get lost, like the bare peer keyword
>>> does.
>>>
>>> Alternatively, you could use some grouping, a la:
>>>
>>> profile SubjectA {
>>>
>>>   dbus bus=session name=SubjectA.service acquire,
>>>   dbus bus=session name=SubjectA.service method=service.method receive,
>>>   dbus bus=session peer(name=a.peer.address) send,
>>>   dbus bus=accessibility name=this.subjects.other.service acquire,
>>>   dbus bus=accessibility name=this.subjects.other.service peer(name=another.peer.address) receive,
>>>   net tcp addr=192.168.0.1 peer(addr=10.1.0.0/24 port=443) send
>>>   net tcp addr=192.168.0.1 peer(port=80) send
>>> }
>>>
>> I am okay with grouping, though I need to ponder the syntax more. What you
>> have is a little different than we have traditionally used for ( )
>>
> 
> From a writer/auditer POV, I think I prefer grouping over everything
> else so far. The context isn't lost within the rule like 'peer' is, the
> grouping is very clear in what it applies to and there is no symbol with
> extra connotational (/me likes to make up words) baggage. It also still
> conveys to me the 'over there' sentiment that jj was looking for since
> it is so separate from the subject.
> 
>> basically we have { } which denote a rule grouping, or are used for
>> alternation in globbing syntax. Grouping could work but I think would not
>> be the best choice (seeing it typed out makes me dislike it even more
>>
>>  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?
> 
> 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.
> 
> 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.
> 
> 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:
> 
>   dbus name=... path=... peer (name=..., interface=...) send,
> 
> 

Well, arguably the most consistent would be tweaking Steve's grouping
slightly to have a rule like this (my previous "I don't want commas for
the subject" comment didn't consider subj()):

dbus bus=... subj=(name=..., path=...) peer=(name=..., path=...) send,

This is exceptionally clear and consistent with other multi-valued sets,
but is verbose ('subj=(name=...' admittedly looks slightly odd with the
two '='s in close proximity, but I can live with that).

Still open, but this is my new favorite (let it sink in for a moment and
I think you may agree :).

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