[Apparmor-dev] rlimit resource limit policies

[Seth Arnold]

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.

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

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

A very good question :) I'm 90% of the way to saying that it gets to
modify the target regardless of policy...

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