Use of empty path_cond in AppArmor kernel code can lead to unexpected permission check results
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
AppArmor |
Triaged
|
High
|
Unassigned |
Bug Description
IMPORTANT: Bug #1620635 should be fixed at the same time as this bug. Fixing
this bug will likely result in broken users of libapaprmor's
aa_query_
The AppArmor kernel code defines the path_cond struct as:
struct path_cond {
kuid_t uid;
umode_t mode;
};
There are several instances where a path_cond instance is initialized as:
struct path_cond cond = { };
This results in a path_cond.uid of 0. The cond variable is then sometimes
passed to functions which conditionalize on the value of path_cond.uid.
An example of this can be seen in callers of aa_compute_
in path_cond is simply zero-initialized and the fsuid of the current process is
0 (root), then the permissions are mapped differently than if the fsuid of the
current process was non-zero (non-root).
That's a problem in profile_query_cb() because it results in any "owner"
conditionals being ignored when a root-owned process performs a file
permissions query via libapparmor's aa_query_
Instead of initializing a path_cond struct to all zeroes, path_cond.uid should
be initialized to INVALID_UID so that it is impossible for the current task's
fsuid to match path_cond.uid.
Here are all of the instances I could find where a path_cond struct is
initialized to all zeroes:
$ git grep -p "path_cond.*{ }" security/apparmor
security/
security/
security/
security/
security/
security/
security/
security/
security/
security/
tags: | added: aa-kernel |