[apparmor] change_hat_v behavior

[John Johansen]

On 07/18/2010 02:55 AM, Steve Beattie wrote:
> On Fri, Jul 16, 2010 at 08:07:20PM -0700, John Johansen wrote:
>> Currently AppArmor does not log change_hat probing failures as that is
>> part of the api (a program may make several attempts to switch before
>> it finds a matching hat).
> 
> This behavior can be particularly true of the mod_apparmor apache module,
> where it can probe a few different hats before hitting one that exists.
> And as far as I'm aware, mod_apparmor is the largest user of the
> interface.
> 
> The current behavior logs change_hat calls for learning mode, correct?

Right it logs the first "failure" in learning mode, where it then
transitions to a null profile and reports that change_hat succeeded.

> 
>> With the addition of change_hat_v a vector of hats is passed, and we
>> could (but don't currently) log a message if no hats are match.  Do
>> we want to make this change?
> 
> I think this is makes sense. If nothing else, we can try it and back it
> out if we don't like it.
> 
> What is the status of change_hat_v(), by the way? I've forgotten, and
> regardless of what we decide here for logging, mod_apparmor should be
> converted over to make use of change_hat_v().
> 
Change_hat_v should be functional in both the kernel and user space libs.
The libs present two functions as the api, they currently have a limit
of 16 hats, as that the maximum that the kernel will currently consider.
Also aa_change_hat_vargs, uses the arg counter macro so the 16 hat limit
is encoded there as well.

int aa_change_hatv(const char *subprofiles[], unsigned long token);

int aa_change_hat_vargs(unsigned int token, ...);