[apparmor] Questions about AppArmor's Kernel Code

[John Johansen]

On 7/26/19 5:56 AM, Abhishek Vijeev wrote:
> Hi,
> 
> 
> I have a few questions about AppArmor's kernel code and would be grateful if you could kindly answer them. 
> 
> 
> 1) Why does AppArmor maintain two separate security blobs in cred->security as well as task-security for processes? For a simple project that requires associating a security context with every task, would it suffice to use just one of these?
> 
the task->security field is used to store task specific information, that is not used for general mediation. Currently the information stored their is for the change_hat and change_onexec apis and some info to track what the confinement was when no-newprivs was applied to the task.

cred->security is used to store the subjects label (type) for mediation.

Before the task->security field was reintroduce all the information was stored off the cred in a intermediate structure. Doing so would cause use of the change_hat and change_onexec api to change the cred of the task even when the confinement had not changed. The switch to using the task->security field was pre 4.18

> 
> 2) There has been a change in the way security blobs are accessed from kernel version 4.18 to 5.2. I see that in v5.2, the security blob's address is obtained by adding the size of the blob to the start address. Why has this change been made? (For reference: https://github.com/torvalds/linux/blob/master/security/apparmor/include/cred.h#L24)
> 
see Casey's answer

> 
> 3) I tried adding a custom field (pointer to a custom structure) to struct aa_profile, at exactly this point - https://github.com/torvalds/linux/blob/master/security/apparmor/include/policy.h#L144. I have taken care to allocate and free memory for the pointer at the appropriate places (allocation is performed here - https://github.com/torvalds/linux/blob/master/security/apparmor/policy_unpack.c#L671 and freeing is performed here - https://github.com/torvalds/linux/blob/master/security/apparmor/policy.c#L205). However, while booting the kernel, it crashes at the function 'security_prepare_creds( )', which I presume invokes 'apparmor_cred_prepare( )'. If I was, to assume for a moment that there are no bugs with my memory allocation code, is there any other reason why such a crash might have occurred? I have attached the kernel crash log file with this email for your kind reference. 
> 

I know the code points but to be able to comment beyond vague guesses I need to see your changes. I can give you the warning to not add your field after the current last field,

  struct aa_label label;

as it has a variable length field. While that is always 2 entries when its embedded in the profile the compiler will end up treating it as zero length over lapping your new field with the start of the variable length array.

I do have a patch to address this using a union but I haven't landed it yet.