Introduction[edit | edit source]
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[edit | edit source]
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.
|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.
|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.|