[apparmor] dbus/pair address rule encoding

[John Johansen]

On 05/09/2013 05:06 PM, Steve Beattie wrote:
> On Thu, May 09, 2013 at 02:41:19PM -0700, John Johansen wrote:
>> On 05/09/2013 02:12 PM, Jamie Strandboge wrote:
>>> 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=...,
>>> }
>>>
>> that is a possibility, though it breaks with the "syntax" of having the
>> permission at the end of the rule. This is actually a case where the
>> permission at the start of the rule makes more sense, than at the tail.
>>
>> (send, receive) dbus name=... interface=... -> name=... path=...,
>>
>> of course I'd like to here seth and steve's input on that
> 
> So, to be explicit, what we're trying to express and make coherent to a
> reader of policy is which "addresses" are local to the confined subject
> and which are specific to a peer, where addresses could be dbus names,
> dbus interfaces, methods, ip addresses, port numbers/ranges, etc.
> 
yes

> I think the difficulty with the current and proposed dbus syntax is
> that we're trying to make it apparent through context, where context
> is which side of an '->' it comes from. We choose this syntax because
yes

> we have other usages of '->', namely for link rules and for policy
> transitions on exec (Cx rules). (Are there other uses?) It works okay
> for the former because there's a clear source, destination pairing for
> the creation of a link. It works for the latter, in part because we
> don't have language or require in policy to specify who can transition
> to the policy, just which policy the subject process can transition to.
> Thus it's strictly unidirectional.
> 
yep

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

> 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

> 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 ( )

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,


> profile SubjectB {
> 
>   dbus bus=session peer(name=SubjectA.service method=service.method) send,
>   net tcp addr=10.1.2.3 port=443 peer(addr=192.168.0.0/16) receive,   # need acquire for accept()?
> }
> 
no actually we will have an accept perm for the networking rules where it
makes sense. The ability to read/write on a socket but not accept new
connections has been asked for over and over again.