[apparmor] Follow-up on IPC syntax

[John Johansen]

So to expand on this for general ipc syntax. After discussing this more
in a mumble based chat we reached have settled on a general direction.
That has a format similar to that outlined by Tyler with the dbus
syntax.

New rules will start with a type keyword (eg. dbus) followed by the
permission set being granted. And then rule specific message and
address information.

So a general form of
  <prefixes> keyword [<permissions>] <rule specific info>,

  <prefixes> audit, deny, ...
  <permissions> set of permissions that are keyword specific. If the
                the permission set is not specified all permissions
                for the keyword are granted.

permissions can be specified as a single word or in a grouping inside
of parenthesis () separated by commas, and or spaces. eg.
  read
  (read)
  (read write)
  (read,write)
  (read, write)

The current single letter permissions will continue to be supported
and count as a single "word", ie.
  rw
  rwlk


If a peer address is to be specified it will be placed in a peer=()
designator. At this time we will not be supporting pairing of local and
peer addresses so that both a local and peer address should not appear
in the same rule.  However pairing may be allowed in the future for
specific types where it makes sense.  So for now/many forms of ipc
the bind permission will need to be in a separate rule from that of
send/receive to a peer.

  inet bind address=192.168.0.10,
  inet (send, receive) address=192.168.0.0/24,

We will be supporting send as an alias perm for write, and receive as an
alias perm for read. This just seems natural for some forms of
communication, and after much debate the use of send/receive 

Old style file, and network rules will continue to be supported. File
will be extended to support the

  <prefix> file [<perm>] <path>,

form, where currently only
  <prefix> file,
  <prefix> <perm> <path>,
  <prefix> <path> <perm>,

are supported

The current network format will not be extended but will be supported
for coarse grained mediation. If a finer grained ability is desired
it can be broken out into its own type (that will accumulate with
network rules).

That is we currently support
  <prefix> network [af] [type],

when an af (address family) has finer grained mediation added the af
will become a keyword that can be used to specify a finer grained rule.

  network inet,   # all inet allowed
  inet,           # the inet keyword equivalent of network inet,

  inet bind address=192.168.1.10,   # a finer grained inet rule


Generic label rules when supported will get their own keyword that is
yet to be determined.

As long as a type does not imply binding an address with creation it
will get an implicit rule that allows creation and default labeling
of the type without a rule, and a task will be allowed to communicate
with its own label by default.

That is there will not be a rule required to create a pipe that defaults
to the tasks labeling, and the task will be able communicate with it
self over the pipe without a rule being specified in the profile.

This default can be overridden with rules. If a task should not be
allowed to create a pipe. A rule can be added.

  deny pipe,

And to communicate with a task with a different label on a pipe
  pipe rw label=foo,

If a form of communication binds an address/name as part of its creation
(files) then it will need a rule specifying the name for it to be allowed