Grsecurity/Appendix/System Resources

Introduction

This table lists all system resources that can be restricted by grsecurity. Grsecurity supports all the resources Linux supports, but uses slightly different names for them: The RLIMIT prefix has been replaced with RES. For example, the Linux resource RLIMIT_CPU is called RES_CPU in grsecurity.

For detailed information about resources in Linux, see the man page of getrlimit.

Syntax and Examples

A single resource rule follows the following syntax:

<resource name> <soft limit> <hard limit>

An example of this syntax would be:

RES_FSIZE 5K 5K

This would prevent the process from creating files that are bigger than 5 Kilobytes.

Using unlimited is valid for both the soft limit and the hard limit, to denote an unlimited resource. Note that by omitting a resource restriction, the system's default limits are used (as set by PAM or the application itself). If a resource is specified within the policy, the specific limits override the system's default limits for the given subject.

A number of suffixes are allowed when specifying resource limits. They are described below.

Suffix	Meaning
s	Amount of time in seconds.
m	Amount of time in minutes.
h	Amount of time in hours.
d	Amount of time in days.
K	Size in kilobytes.
M	Size in megabytes.
G	Size in gigabytes.

A full list of supported resources is supplied below.

Resource Name	Meaning
RES_AS	The maximum size of the process's virtual memory (address space) in bytes.
RES_CORE	Maximum size of core file, in bytes. When 0 no core dump files are created. When non-zero, larger dumps are truncated to this size.
RES_CPU	CPU time limit in seconds.
RES_DATA	The maximum size of the process's data segment, in bytes (initialized data, uninitialized data, and heap).
RES_FSIZE	The maximum size of files, in bytes, that the process may create.
RES_LOCKS	A limit on the combined number of flock() locks and fcntl() leases that this process may establish.
RES_MEMLOCK	The maximum number of bytes of memory that may be locked into RAM. In effect this limit is rounded down to the nearest multiple of the system page size.
RES_MSGQUEUE	Specifies the limit on the number of bytes that can be allocated for POSIX message queues for the real user ID of the calling process
RES_NICE	Specifies a ceiling to which the process's nice value can be raised using setpriority(2) or nice(2).
RES_NOFILE	Specifies a value one greater than the maximum file descriptor number that can be opened by this process.
RES_NPROC	The maximum number of threads that can be created for the real user ID of the calling process.
RES_RSS	Specifies the limit (in pages) of the process's resident set (the number of virtual pages resident in RAM). This limit only has effect in Linux 2.4.x, x < 30.
RES_RTPRIO	Specifies a ceiling on the real-time priority that may be set for this process using sched_setscheduler(2) and sched_setparam(2).
RES_SIGPENDING	Specifies the limit on the number of signals that may be queued for the real user ID of the calling process. Both standard and real-time signals are counted for the purpose of checking this limit.
RES_STACK	The maximum size of the process stack, in bytes.
RES_RTTIME	Specifies a limit on the amount of CPU time that a process scheduled under a real-time scheduling policy may consume without making a blocking system call. for the purpose of this limit, each time a process makes a blocking system call, the count of its consumed CPU time is reset to zero. The CPU time count is not reset if the process continues trying to use the CPU but is preempted, if its time slice expires, or if it calls sched_yield(2). Upon reaching the soft limit, the process is sent a SIGXCPU signal. If the process catches or ignores this signal and continues consuming CPU time, then SIGXCPU will be generated once each second until the hard limit is reached, at which point the process is sent a SIGKILL signal. The intended use of this limit is to stop a runaway real-time process from locking up the system.
RES_CRASH	This is a pseudo-resource interpreted only by the RBAC system. The meaning of soft and hard limits are overridden for this resource. The intent of the resource is to be able to rate-limit bruteforced exploit attempts for a given subject. The soft limit for this resource is the number of times the subject is allowed to crash in ways that suggest an exploitation attempt. The hard limit specifies the amount of time those crashes are allowed to occur in. With a rule like RES_CRASH 3 30m one can limit a privileged binary to three exploit attempts every 10 minutes, deterring bruteforcing attempts. The RBAC system actively responds to bruteforcing attempts that overstep this limit. If the target is a setuid binary, the attacker has all of his/her processes killed and will be unable to log in for the remainder of the configured time. If the target is a forking network daemon, that daemon will be unable to fork additional copies of itself for the remainder of the configured time.