13.9 Guarding Against Resource Starvation Attacks on Unix

13.9.1 Problem

You need to prevent resource starvation attacks against your application.

13.9.2 Solution

The operating system does not trust the applications that it allows to run. For this reason, the operating system imposes limits on certain resources. The limitations are imposed to prevent an application from using up all of the available system resources, thus denying other running applications the ability to run. The default limits are usually set much higher than they need to be, which ends up allowing any given application to use up far more resources than it ordinarily should.

Unix provides a mechanism by which an application can self-impose restrictive limits on the resources that it uses. It's a good idea for the programmer to lower the limits to a point where the application can run comfortably, but if something unexpected happens (such as a memory leak or, more to the point, a denial of service attack), the limits cause the application to begin failing without bringing down the rest of the system with it.

13.9.3 Discussion

Operating system resources are difficult for an application to control; the pooling approach used in threads and sockets is difficult to implement when the application does not explicitly allocate and destroy its own resources. System resources such as memory, CPU time, disk space, and open file descriptors are best managed using system quotas. The programmer can never be sure that system quotas are enabled when the application is running; therefore, it pays to be defensive and to write code that is reasonably aware of system resource management.

The most basic advice will be long familiar from lectures on good programming practice:

• Avoid the use of system calls when possible.

• Minimize the number of filesystem reads and writes.

• Steer away from CPU-intensive or "tight" loops.

• Avoid allocating large buffers on the stack.

The ambitious programmer may wish to replace library and operating system resource management subsystems, by such means as writing a memory allocator that enforces a maximum memory usage per thread, or writing a scheduler tied to the system clock which pauses or stops threads and processes with SIGSTOP signals after a specified period of time. While these are viable solutions and should be considered for any large-scale project, they greatly increase development time and are likely to introduce new bugs into the system.

Instead, you may wish to voluntarily submit to the resource limits enforced by system quotas, thereby in effect "enabling" quotas for the application. This can be done with the setrlimit( ) function, which allows the resources listed in Table 13-1 to be limited. Note, however, that not all systems implement all resource limits listed in this table. Exceeding any of these limits will cause runtime errors such as ENOMEM when attempting to allocate memory after RLIMIT_DATA has been reached. On BSD-derived systems, two exceptions are RLIMIT_CPU and RLIMIT_FSIZE, which raise the SIGXCPU and SIGXFSZ signals, respectively.

Table 13-1. Resources that may be limited with setrlimit( )

Resource	Description
RLIMIT_CORE	Maximum size in bytes of a core file (see Recipe 1.9)
RLIMIT_CPU	Maximum amount of CPU time in seconds
RLIMIT_DATA	Maximum size in bytes of .data, .bss, and the heap
RLIMIT_FSIZE	Maximum size in bytes of a file
RLIMIT_NOFILE	Maximum number of open files per process
RLIMIT_NPROC	Maximum number of child processes per user ID
RLIMIT_RSS	Maximum resident set size in bytes
RLIMIT_STACK	Maximum size in bytes of the process stack
RLIMIT_VMEM	Maximum size in bytes of mapped memory

The setrlimit( ) function has the following syntax:

struct rlimit {     rlim_t rlim_cur;     rlim_t rlim_max; };     int setrlimit(int resource, const struct rlimit *rlim);

The resource parameter is one of the constants listed in Table 13-1. The programmer may increase or decrease the rlim_cur field at will; increasing the rlim_max field requires root privileges. For this reason, it is important to read the rlimit structure before modifying it in order to preserve the rlim_max field, thus allowing the system call to complete successfully. The current settings for rlim_cur and rlim_max can be obtained with the getrlimit( ) function, which has a similar signature to setrlimit( ):

int getrlimit(int resource, struct rlimit *rlim);

We've implemented a function here called spc_rsrclimit( ) that can be used to conveniently adjust the resource limits for the process that calls it. It does nothing more than make the necessary calls to getrlimit( ) and setrlimit( ). Note that the signal handlers have been left unimplemented because they will be application-specific.

#include <sys/types.h> #include <sys/time.h> #include <sys/resource.h>     static int resources[  ] = {   RLIMIT_CPU, RLIMIT_DATA, RLIMIT_STACK, RLIMIT_FSIZE, #ifdef RLIMIT_NPROC   RLIMIT_NPROC, #endif #ifdef RLIMIT_NOFILE   RLIMIT_NOFILE, #endif #ifdef RLIMIT_OFILE   RLIMIT_OFILE, #endif   -1 };       void spc_rsrclimit(int max_cpu, int max_data, int max_stack, int max_fsize,                    int max_proc, int max_files) {   int           limit, *resource;   struct rlimit r;        for (resource = resources;  *resource >= 0;  resource++) {     switch (*resource) {       case RLIMIT_CPU:    limit = max_cpu;    break;       case RLIMIT_DATA:   limit = max_data;   break;       case RLIMIT_STACK:  limit = max_stack;  break;       case RLIMIT_FSIZE:  limit = max_fsize;  break; #ifdef RLIMIT_NPROC       case RLIMIT_NPROC:  limit = max_proc;   break; #endif #ifdef RLIMIT_NOFILE       case RLIMIT_NOFILE: limit = max_files;  break; #endif #ifdef RLIMIT_OFILE       case RLIMIT_OFILE:  limit = max_files;  break; #endif     }     getrlimit(*resource, &r);     r.rlim_cur = (limit < r.rlim_max ? limit : r.rlim_max);     setrlimit(*resource, &r);   } }

13.9.4 See Also

Recipe 1.9