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. -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
