[Apparmor-dev] rlimit resource limit policies

Crispin Cowan crispin at novell.com
Mon Apr 9 03:00:15 MDT 2007


For about a year, we have been wanting to add resource limit policy
features to AppArmor, so that a policy can limit the resources a
confined process can use, and thus limit the ability of an attacker to
DoS the host machine.

Naturally, Linux already has resource limiting features in the form of
rlimit and ulimit. Unfortunately, similar to POSIX.1e capabilities, the
management interface sucks, to say the least. Also similar to
Capabilities, we can ease this situation by providing easy-to-manage
resource limit policies in AppArmor profiles.

See man 2 getrlimit and setrlimit, and man 1 ulimit. Using the system
calls getrlimit() and setrlimit(), a process can voluntarily set its
resource limits for a bunch of attributes, and the kernel will enforce
these limits if the process is not privileged. The proposed design is
that you be able to write such resource limits into a profile, e.g.

/usr/bin/foo {
    capability chown, # a classic POSIX.1e Capability limit
    rlimit_as 1048576, # set address space limit to 1MB
    rlimit_nofile 6, # can have 6 file descriptors
    rlimit_nproc 10, # can have 10 instance processes in this profile
..
}

The man page has the full set of attributes. Most of these attributes
are naturally applied per process, e.g. rlimit_as is the size of the
address space, and rlimit_nofile is the number of open file descriptors
a process may have. Limiting these resources is performed by the kernel:
all AppArmor has to do is set the limits when the process is instantiated.

rlimit_nproc is special: this is the number of processes possible. In
the classic parlance of rlimit, this is the number of processes in the
current real user_ID. I propose that for AppArmor policy purposes, we
change it to be the number of processes that can be instantiated under
this profile. If the limit is exceeded, then fork or exec will fail on
attempts to create another process via ix permissions. However, the
process is still free to launch Px, px, and Ux children, subject to the
rlimit_nproc policy of the corresponding profiles for Px and px.

An important implementation issue is restricting root's resource usage.
I did some experimenting with setrlimit() and was disappointed to
discover that it doesn't actually enforce against root. As with the rest
of AppArmor, we will need to enforce these limits regardless of whether
the process is privileged.

Automatically creating these policy limits in learning mode will be
difficult. A natural semantic would be to set high water marks for these
values in learning mode, but the kernel lacks a high water mark
mechanism for these limits, so we would have to fake it by setting the
limits to minimal values, catching the exceptions, and changing the
limits, without failing the system calls from the requesting processes.
It is also problematic that I suspect that a vast majority of confined
processes won't want to bother with specifying these limits, so learning
mode should only learn limits for explicitly declared attributes.
Enforce mode similarly should only enforce limits for explicitly
declared attributes.

So no matter how it is done, as far as I can tell manipulating rlimit
attributes involves hand-editing of profiles.

Does this design sound useful?

So why am I posting this now? Two reasons:

   1. A member of the AppArmor community privately expressed interest in
      building this feature, because the SUSE AppArmor team is doing
      other stuff right now.
   2. John Johansen (part of the SUSE team) has actually implemented a
      partial prototype of rlimit code. He is critical path on some
      other fun features we are planning for 10.3, so he can't work on
      it in time for 10.3.

I've asked JJ to post his prototype work in response to this thread.
I'll let the other party out themselves at their leisure.

Thanks,
    Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Training at CanSec West   http://cansecwest.com/dojoapparmor.html




More information about the Apparmor-dev mailing list