[apparmor] Follow-up on IPC syntax

[John Johansen]

On 07/09/2013 05:15 AM, John Johansen wrote:
> 
> 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
> 

So questions where raised about this behavior as it does not follow the
general guideline of no implicit rules, and it doesn't allow for easy
behavioral based profiling.

That is an application asking for a pipe when it is not expected could
be an indication of something being wrong.

With the currently proposal of an implicit rule you would need to
deny any type that was not expected. You could not do a general deny
because deny rules take precedence over allow rules.

So what are the alternatives?

1. Partial implicit.

We allow only read, write on @{self} implicitly. This would mean to
create, pipes, anonymous sockets etc that you would need a rule. But
you wouldn't need a rule to read, write and existing file descriptor
that is passed to the task as long as it has the same labeling.

2. No implicit.

In this case a rule would need to be provided for every type expected.
However a generic label rule could be used to get the implicit rule
behavior.

That would look something like (details to be fully worked out)
  any (read, write, create) label=@{self},

and if you just wanted to emulate the proposed implicit behavior for
a specific type, for a given profile
  pipe (read, write, create) label=@{self},

or in the case of pipes (or any types) which don't have addresses
  pipe label=@{self},