[apparmor] Follow-up on IPC syntax

[John Johansen]

On 07/09/2013 08:55 AM, John Johansen wrote:
> 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},
> 
> 

So at todays meeting we decided to try explicit rules and see how
policy turns out, and reevaluate after we have some experience with
this issue