[Apparmor-dev] rlimit resource limit policies

[Steve Beattie]

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.

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

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

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

> > >   - should a task be able to lower its limits if limits are set by profile
> > >   - should a task be able to raise its limits as long as the limits
> > >     are not > the values set by the profile
> > >   
> > I'd say no, mostly for simplicity and because I don't think it is necessary.
> > 
> Actually I think its a definate yes for soft limits, up to the hard limit
> value (no extra work).
> 
> And I think yes for the hard limit if the profile has CAP_SYS_RESOURCE.
> This comes about because of the differences in = and <= (see below)
> 
> > > /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.

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.

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.

-- 
Steve Beattie
SUSE Labs, Novell Inc. 
<sbeattie at suse.de>
http://NxNW.org/~steve/
-------------- 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/7643d66f/attachment.pgp