Role-Based Access Control (RBAC)

Role-based access control (RBAC) is a method that allows and restricts access to subjects or users based on the role of the user. When reading, pay attention to the description of an RBAC system and be able to describe the system, as well as to name the user that only RBAC can restrict. How does this one restriction increase the difficulty for an attacker to compromise the system? What is the set of rules called that manages the RBAC system? Although you will not be asked to create an RBAC policy, read through the rest of the document and try to follow the examples of how an RBAC policy is coded on a system.

9. Resource Restrictions

One of the features of grsecurity's ACL system is process–based resource restrictions. Using this feature allows you to restrict things like how much memory a process can take up, how much CPU time, how many ﬁles it can open, and how many processes it can execute. Also in this section, we will discuss a "fake" resource implemented in grsecurity's ACL system called "RES_CRASH" that helps guard against bruteforce exploit attempts, which is necessary if you're using PaX.

A single resource rule follows the following syntax:

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

An example of this syntax would be:

RES_NOFILE 3 3

This would allow the process to open a maximum of 3 ﬁles (all processes have 3 open ﬁle descriptors at some point: stdin (standard input), stdout (standard output), and stderr (standard error output)).

To clarify what the soft limit and hard limit are, the soft limit is the limit assigned to the process when it is run. The hard limit is the maximum point to which a process can raise the limit via setrlimit(2), unless they have CAP_SYS_RESOURCE. In the case of RES_CPU, when the soft limit is overstepped, a special signal is sent to the process continuously. When the hard limit is overstepped, the process is killed.

A person who is less familiar with Linux should stick to setting limits on the number of ﬁles, the address space limit, and number of processes. Of course, you can always use the learning mode of grsecurity to set the resource limits for you. The RES_CPU resource is the only one that accepts time as limits. The time defaults to units of milliseconds. You can also append a case sensitive unit to your limit.

Some examples would be:

100s – 100 seconds
25m – 25 minutes
65h – 65 hours
2d – 2 days

The other resources either operate on a number itself or on a size, in bytes. For these you can use the following units: K, M, and G, like:

2G – 2 billion
25M – 25 million
100K – 100 thousand

If you don't want any restriction for the soft or hard limit for a resource, you can use "unlimited" as the limit. Here are some more examples to help you understand how this works:

subject /bin/bash
       /               r
       /opt            rx
       /home           rwxcd
       /mnt            rw
       /dev
       /dev/grsec      h

       RES_CPU 25m 30m
       RLIMIT_AS 5M 5M
       RLIMIT_NPROC 2 2
       RLIMIT_FSIZE 5K 10K
...

For a list of accepted resource names and units, see System Resources.

RES_CRASH

This "fake" resource limit is expressed by using the name "RES_CRASH" and has the following syntax:

RES_CRASH <number of crashes> <amt. of time>

For example, if you wanted to allow the program to crash once every 30 minutes, you would use the following:

RES_CRASH 1 30m

What happens when this threshold is reached? Well, the only way to ensure that the process won't crash again is to keep it from being executed. If the process is a suid/sgid binary run by a regular user, we kill all processes of that regular user and keep them from logging in for the amount of time, speciﬁed as the second parameter to the RES_CRASH resource. So for the above example, the user would be locked out of the system for 30 minutes. If the process is not a suid/sguid binary, we simply keep the binary from being run again for the amount of time speciﬁed as the second parameter to the RES_CRASH resource, after killing all processes of that binary.