[Apparmor-dev] rlimit resource limit policies

[Crispin Cowan]

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:
>>>       
>>>> currently you need extra space of 1 process to do px, ux transition.  A
>>>> fork clone is accounted for before the exec is done.  Once the exec happens
>>>> the count will be increase for the profile being transitioned to, and
>>>> reduced for the profile the fork was done under.  
>>>>         
>>> Doesn't this argue for having an implicit "+1" on num_proc? So that a
>>> user can intuitively say "I want 10 Apache daemons, so I will set this
>>> limit to 10"?
>>>       
>> perhaps - but then that would also allow 11 processes if something wasn't
>> execing.  I don't think it really matters either way.  I was more attempting
>> to describe the current state of things.
>>     
> This is potentially insufficient, you could have multiple
> threads/processes wanting to do a px/ux transition at the same time; if
> a schedule event occurs between the fork() and exec() for one of them,
> the rest will fail, even if they legitimately (under a perfectly accounted
> system) could have succeeded.
>   
If it is merely the case that concurrent oversubscribing requests fail,
that is what I would call a "tough luck situation" :)

Of much more concern would be if it deadlocks, with each requester half
done and not relinquishing the resources the other needs. Of course,
aggressive processes can deadlock each other if they really want to in a
resource-constrained situation; the real concern is whether oblivious
processes, coded without AA/ulimits in mind, would deadlock due to
unfortunate timing.

>>>> - resolve semantics around a task setting its rlimits
>>>>   - should CAP_SYS_RESOURCE allow a task to override the profiles HARD_LIMIT
>>>>   - should CAP_SYS_RESOURCE allow a task to ovveride the profiles SOFT_LIMIT  
>>>>         
>>> I say "yes" to both of these, and conversely, the process does not get
>>> to mess with profile limits without this capability.
>>>       
>> 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.

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

>> 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 :)

> 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

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com