[Apparmor-dev] rlimit resource limit policies

[John Johansen]

> >> the soft limit I think is an obvious yes.  In fact I think the application
> >> should be able to adjust its soft limit as normal, even without
> >> CAP_SYS_RESOURCE.  Giving the profile the ability to set the soft limit
> >> is just a convience.
> >>     
> > Hmm, I'm not convinced there's much value in AppArmor looking at soft
> > limits, as they're entirely discretionary.
> >   
> That's my thought, but JJ disagrees.

disagrees is a little strong.  More like I saw it as possibly having
some value in convience so I added to the prototype.  I am unsure
whether it should stay.

> 
> Without a compelling argument, I'd be happy to give Trolltech "cook's
> privilege" to implement soft limit controls if they want to, or not. The
> important part is to implement hard limits.
> 
yep

> > Err, wait. I didn't look at the patchset (sorry!); does this mean
> > that the prototype modifies the kernel's notion of limits, and doesn't
> > keep/check seperate apparmor-specified limits? I can see why from an ease
> > of implementation perspective, but note that this works differently from
> > file permissions and capabilities.
> >   
> Hijacking and setting the kernel's existing resource limits is what I
> expected the code to do, and what was discussed in the research meetings
> when we did discuss it. The main reason to prefer this is that LSM does
> not necessarily give us enough hooks to mediate resource limits
> ourselves. We could end up having to propose a heavy set of hooks to be
> able to implement our own limits. And then certain people would complain
> about why aren't we using the existing upstream infrastructure :)
> 
if there is value in adding hooks to the kernel then we should.  It
could probably be done with a single hook.  The question is if that hook
would get accepted upstream.

> > My vaguely desired behavior is only the "<=" behavior on hard limits,
> > and ignore soft limits from apparmor's perspective. An application
> > w/CAP_SYS_RESOURCE would be able to modify the kernel's notion of hard
> > limits but not exceed the AppArmor notion of the hard limits. This would
> > be much more consistent with the way file and capability mediation occurs.
> >   
> Seems to me we can get close to what Steve wants here by having
> CAP_SYS_RESOURCE permit messing with the soft limits, but not the hard
> limits.
> 
we get close to the behavior by just using <= and not allowing
tasks to raise their hard limits even if they have CAP_SYS_RESOURCE.

The current behavior allows a task with CAP_SYS_RESOURCE to raise its
hard limit up to what is specified in the profile.

The resource assignment (=) can be thought of as a convience just
like soft limits.  It allows a profile to raise the hard limit.
The question is, is that desirable and is the profile the right place to
do it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-dev/attachments/20070507/38b55aa3/attachment.pgp