[apparmor] Changing null learning profile name and behavior

[John Johansen]

On 11/18/2014 07:43 PM, Jamie Strandboge wrote:
> On 11/18/2014 05:59 PM, John Johansen wrote:
>> So this was brought up again today, which reminded me of a patch I have
>> been working on that changes the behavior of complain/learning mode
>> around the null profile.
>>
>> Currently when in complain/learning mode if an exec is done to an
>> application that does not have a match an existing rule, a new subprofile
>> is created with the name
>>
>>   null-XXXX 
>>
>> where XXXX is a unique number.
>>
>> The exec transition is logged and subsequent accesses by the task are
>> logged via the new name. So for example if the exec was done from profA
>> the new learning profile would be named
>>
>>   profA//null-XXXX
>>
>> if the task confined by the profA//null-XXXX profile subsequently does
>> an exec it will create a new subprofile
>>
>>   profA//null-XXXX//null-YYYY
>>
>> and logging will continue under this name.
>>
>> This scheme had the advantage of keeping a name hierarchy and keeping
>> the profile names relatively small, but it also has a couple of
>> disadvantages. It looses the executable name of the application and if
>> a task execs the same application multiple times each of those
>> executions get a unique null-XXXX profile. Both of which make logs
>> harder to understand, and in kernel duplicate error elimination less
>> useful.
>>
>> The patch proposes to change how the null tracking profiles are named.
>> Instead of using a uniq XXXX for the profile name, it will be created
>> with a name based on the application name, and if for some reason this
>> name is too long the profile will fall back to the null-XXXX scheme
>>
>> eg. if /bin/foo is executed from profA this will create a profile named
>>
>>   /bin/foo//null-/bin/baz
>>
>> and if this profile execs app /bin/bar the null sub profile would be
>>
>>   /bin/foo//null-/bin/baz//null-/bin/bar
>>
>> The null- prefix is retained as a hint that a given profile is a null
>> learning profile (nice for human inspection of policy), and also for
>> consistency with the fallback.
>>
>> We could drop the use of the null- prefix for the case where the
>> application name is used but I think keeping the null- prefix has value.
>>
>> Any objections to the change?
>>
> I think this is a fantastic idea. My only question is around the userspace tools
> handling the change, but others will certainly have more informed questions.
> 
The userspace tools would need to be updated.

With the null- prefix there should be very little work, as it is basically the
same format (another reason for keeping the null- prefix), I just can't guarantee
that they aren't filtering the current XXXX as only allowing hex digits.

Once that is fixed the new format should just work. There is additional work
that could be done to extract the executable name from the log entries for
the case where the exec transition entry is lost, basically this will let us
have a better recovery, instead of having to just throw the log entries
away because we don't know what they are from.