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>

diff --git a/security/apparmor/resource.c b/security/apparmor/resource.c
index 748bf0ca6c9f74572c601ebdaf033c6da224a20e..67a6072ead4b9ed8efe98bdc57080c615839c32a 100644 (file)
--- a/security/apparmor/resource.c
+++ b/security/apparmor/resource.c
@@ -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;