[apparmor] dbus/pair address rule encoding

[Steve Beattie]

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.

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

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.

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
}

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
}

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


-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130509/221b7e44/attachment.pgp>