[Apparmor-dev] rlimit resource limit policies

[John Johansen]

On Mon, May 07, 2007 at 02:53:02PM -0700, 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.
> 
The problem here is that most programs follow the fork/exec behavior
and they can sleep at any time between the fork and exec.  We can't
account for which ones are going to exec because we just don't know
until it happens.

> > > > Another possibility (which the prototype does NOT do) is to inherit
> > > > limits across px if current profile has set limits and the profile
> > > > being transitioned to does not.
> > > >   
> > > I think I'd rather not do that.
> > > 
> > I'm not terribly fond of it either but it may have its uses, it is
> > certainly worth talking about, so that we can arrive at the exact semantics
> > we want.
> 
> > > Each profile should describe how many units of that profile get to run.
> > > If you don't want to grant access to that, then specify px for a
> > > different profile (using the hardlink hack or something like it).
> > > 
> > > This makes it relatively easy to reason about what your system will do
> > > under load or under attack. If you want a given entry point to be
> > > num_proc limited, then ensure that every px leads to a profile that is
> > > also num_proc limited.
> > > 
> > > If you provide for inheritance across px, then the limits on a profile
> > > become a complex combination of the profile and its context.
> > > 
> > yeah that is what really makes me dislike it.
> 
> Anonymous profile transitions are probably more useful for this
> situation.
> 
sorry I am not following, what do you mean by an anonymous profile transition

> > > > - 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.
> 
Yes, and in the prototype they are too, its just a matter of convience
allowing the profile to set an initial soft limit.

> > > > /foo {
> > > >
> > > >   rlimit nproc = 100,		# set maximum tasks using this profile
> > > >   rlimit nofile <= 50,		# set maximum files to min(current->limit,50)
> > > >
> > > >   soft_rlimit rss = 500K,	# set soft RSS limit to 500K
> > > > }
> > > >   
> > > You never specified what the difference is between = and <=. If there is
> > > no difference, then I suggest deleting the symbol entirely and going
> > > with "rlimit nproc 100,"
> > > 
> > 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.
> 
yes.  each profile gets its own set of limits, which then can be set
the tasks limits.  They can be either set to what specified in
the profile, or set to be the lesser of what is in the profile and
what the tasks limit structure currently holds.

It would be nice if there where call out hooks for the limits stuff
but currently there isn't and the prototype didn't add them.  It would
certainly be nicer if there were hooks for the rlimits stuff.

> 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.
> 
right.  Adding the soft limit stuff was just for conviently setting the
soft limit for processes that get confined.  I could see it going away.

I understand the desire to keep the hardlimit behavior to only <=
style, but I can see a convience factor in allowing a profile to raise
it, just like its convient to allow a profile to specify a soft limit.

> 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.
> 
heh, I would think as long as it was the same policy, up to
the profile specified limit.
-------------- 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/c75ebf99/attachment.pgp