[apparmor] [PATCH] apparmor: allow SYS_CAP_RESOURCE to be sufficient to prlimit another task

[John Johansen]

On 11/06/2015 12:17 PM, Jeff Mahoney wrote:
> 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 overriden
> using a value that means unlimited for a particular resource.
> 
> Signed-off-by: Jeff Mahoney <jeffm at suse.com>

thanks jeff, I'll pull it for my next push to upstream

Acked-by: John Johansen <john.johansen at canonical.com>


> ---
>  security/apparmor/resource.c |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> --- a/security/apparmor/resource.c
> +++ b/security/apparmor/resource.c
> @@ -101,9 +101,11 @@ int aa_task_setrlimit(struct aa_profile
>  	/* 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(current, profile, CAP_SYS_RESOURCE, 1)) ||
>  	    (profile->rlimits.mask & (1 << resource) &&
>  	     new_rlim->rlim_max > profile->rlimits.limits[resource].rlim_max))
>  		error = -EACCES;
>