forked from luck/tmp_suning_uos_patched
apparmor: allow SYS_CAP_RESOURCE to be sufficient to prlimit another task
While using AppArmor, SYS_CAP_RESOURCE is insufficient to call prlimit on another task. The only other example of a AppArmor mediating access to another, already running, task (ignoring fork+exec) is ptrace. The AppArmor model for ptrace is that one of the following must be true: 1) The tracer is unconfined 2) The tracer is in complain mode 3) The tracer and tracee are confined by the same profile 4) The tracer is confined but has SYS_CAP_PTRACE 1), 2, and 3) are already true for setrlimit. We can match the ptrace model just by allowing CAP_SYS_RESOURCE. We still test the values of the rlimit since it can always be overridden using a value that means unlimited for a particular resource. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: John Johansen <john.johansen@canonical.com>
This commit is contained in:
parent
38dbd7d8be
commit
ff118479a7
|
@ -101,9 +101,11 @@ int aa_task_setrlimit(struct aa_profile *profile, struct task_struct *task,
|
|||
/* TODO: extend resource control to handle other (non current)
|
||||
* profiles. AppArmor rules currently have the implicit assumption
|
||||
* that the task is setting the resource of a task confined with
|
||||
* the same profile.
|
||||
* the same profile or that the task setting the resource of another
|
||||
* task has CAP_SYS_RESOURCE.
|
||||
*/
|
||||
if (profile != task_profile ||
|
||||
if ((profile != task_profile &&
|
||||
aa_capable(profile, CAP_SYS_RESOURCE, 1)) ||
|
||||
(profile->rlimits.mask & (1 << resource) &&
|
||||
new_rlim->rlim_max > profile->rlimits.limits[resource].rlim_max))
|
||||
error = -EACCES;
|
||||
|
|
Loading…
Reference in New Issue
Block a user