[Apparmor-dev] rlimit resource limit policies

[Sarah Smith]

On Tuesday 08 May 2007 11:25, Crispin Cowan wrote:
> Steve Beattie wrote:
> > On Fri, May 04, 2007 at 01:37:48AM -0700, John Johansen wrote:
> >> On Thu, May 03, 2007 at 08:46:53PM -0700, Crispin Cowan wrote:
> >>> John Johansen wrote:

> >> 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.
>
> 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.

I'm keen to minimize work. From the viewpoint also of smaller changes are less 
likely to contain bugs, as much as laziness.  :-)

My main thing with soft limits is that the semantics are preserved.  For 
example if some kind of reporting system is hooked up to the logs - as it 
will be in our application, or as it might be in the case of server boxen 
monitored with nagios etc - that breaches of soft limits do not cause a 
notifiable alert condition.

>
> >> The hard limit I am less sure on but why I am thinking it shouldn't be
> >> able to.  Why would you be setting a hardlimit in the profile if the
> >> application can override it?
> >
> > Agreed; we don't allow application with CAP_DAC_OVERRIDE to access file
> > locations not in their policy, we don't allow processes with CAP_SETPCAP
> > to grant more capabilities than what's in their policy (from an apparmor
> > perspective), we should do the same for hardlimits.
>
> Excellent point. Ok, I'm convinced that CAP_SYS_RESOURCE should not
> allow a process to override its AppArmor ulimits.

Ok.

>
> >> well actually I do in the comment to the right, but yeah I should have
> >> explained that better.
> >>
> >> The prototype currently supports 2 forms for setting the limit.
> >> = sets the limit to the specified value
> >>
> >> <= sets the limit to be less than or equal (<=) to the specified value
> >>    specifically it takes the minimum of the tasks current limit and
> >>    the profile specified limit.
> >>    This allows a profile to specify a maximum value without raising
> >>    an existing limit that could be lower.
> >
> > 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 :)

Agreed.
>
> > 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.
>
> > Another question would be an whether an application w/CAP_SYS_RESOURCE
> > is allowed to modify another application's rlimits, when the target
> > application is under the same apparmor policy, a different apparmor
> > policy, or no policy at all.
>
> Hmmm. I hadn't realized that one process got to change another process's
> limits. We could do that here, or in the IPC work
> http://forge.novell.com/pipermail/apparmor-dev/2007-April/000503.html

Ok, in the way that some app could change another apps caps with setcap.  

I could see this as needed functionality, but a feature for down the track.

Rgds
-- 
Sarah Smith BSc MACS
Senior Software Engineer
Ph +61 7 321 999 06 x109
Trolltech (Australia) Pty Ltd