[Apparmor-dev] rlimit resource limit policies

[John Johansen]

On Mon, May 07, 2007 at 03:48:30PM -0700, Seth Arnold wrote:
> On Mon, May 07, 2007 at 02:53:02PM -0700, Steve Beattie wrote:
> > Hmm, I'm not convinced there's much value in AppArmor looking at soft
> > limits, as they're entirely discretionary.
> 
> I can see a case for soft limits: sysadmin says "it would be nice if
> mutt doesn't go above twenty megabytes, but if users need, they can use
> up to fifty".
> 
> Of course, very few programs provide for changing softlimits once the
> software is running, so maybe it is pointless. But it is also seems easy
> to provide. (Learning mode behaviour may be more difficult, but honestly
> rlimits learning mode support doesn't seem important to me.)
> 
> > 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.
> 
> I believe that the implementation that just provides another mechanism
> for setting the kernel's rlimits _and_ mediating the setrlimit(2)
> interface appropriately we can provide semantics as you wish.
> 
yes it only provides a way of setting them.  And the prototype does mediate
setrlimit, disallowing confined applications with CAP_SYS_RESOURCE from
raising their hard_limit passed what is specified in the profile.

This does mean that an application with CAP_SYS_RESOURCE may be able to
raise its hardlimit if it was set with <= and the tasks limit was less than
that specified in a profile.

The bigger problem with just setting the tasks resources is that their
is currently no way to change the resource back to what it was if confinement
is dropped/changed.  It would be possible to save off old confinement
data in the aa_task_context but a hook mechanism would be better.

An interesting question about resource inheritance pops up here as well.
In the current protype the reduced limit is inherited, so that
- unconfining a task leaves it with the reduced limit
- transition to a another profile which controls a reduced limit using <=
  compares against the tasks reduced limit
- transition to another profile which doesn't control the same limits
  results in the reduced limits being inherited

obviously inheriting the reduced limit could be nice in some cases
but isn't desirable for all.  So is it worth being able to distinguish
between those cases.

> (In fact, I think we could do the same for capabilities, just use the
> kernel's existing datastructures, but the oddball exec() behaviour would
> wreck it. rlimits at least aren't reset across exec()..)
> 
why would we do that we control capability completely with the capable
hook.  We could implement a version of capability that never used
that tasks capability structure.

In fact I have a patch which provides a set_capability function to
profiles, that gives profiles the ability to something similar to fscaps.
Where a profile can give a task some of roots capabilities without
the task having to be root.  What happens is that when the capability
is called it checks the set_capability mask first - if set it returns
that the task has the capability, if not it goes through the
regular test task->capabilies and if set test profile->capabilities.

Of course the question becomes is this an ability we want AA to
have, or should we just stack with fs caps.

-------------- 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/cc9d083d/attachment.pgp