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 <[email protected]>
thanks jeff, I'll pull it for my next push to upstream Acked-by: John Johansen <[email protected]> > --- > 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; > -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
