2.2. Architecture
Figure 2-1 shows a schematic overview of the architecture. The GFAC model has been translated into Linux kernel code that decides which calls are allowed (the ADF) and another block of code that enforces these decisions (the AEF). The AEF is by nature operating system specific and therefore it was kept as small as possible, as one of RSBAC's design goals was portability. The ADF contains most of the code and was written as platform independent as possible. RSBAC should be easy to port to (for example) FreeBSD or proprietary Unices like HP-UX, Solaris and AIX. RSBAC uses kernel memory to implement a storage area for its status data, the ACI. Each block is described in more detail next:
2.2.1. ACI Access Control Information
This block contains all functionality that takes care of the (internal) RSBAC administration like locking information and linked lists. This data will be kept in kernel memory. Communication between AEF and ADF is mostly done using the ACI data. The code in this block also keeps track of the status of calls. If so configured, the data in the ACI will be flushed to disk regularly. Data will be stored in special directories. For each filesystem that needs to be mounted one such directory will be created. These directories are either named /rsbac (up to version 1.2.0) or /rsbac.dat (version 1.2.0), for example: /var/rsbac.dat or /usr/rsbac.dat etc. Note, however, that the ACI does not store decision rules: these are hardcoded as decision modules. Each module forms one rule set.
2.2.2. AEF Access control Enforcement Facility
This block comprises of functionality to intercept and possibly deny Linux kernel calls to processes. The AEF will fetch status-data from the ACI and will communicate with the ADF (described later) to learn whether or not it needs to grant access to the system call. The AEF will either deny or grant the call accordingly and will notify the ADF.
2.2.3. ADF Access control Decision Facility
This code receives a notification from the AEF when a process issued a kernel system call. Any related data will be fetched from the ACI and a chain of decision modules will be traversed. Each module will independently decide whether or not the call is acceptable, based on the model it implements and the parameters and context of the call. At the end of the chain some modules may have denied access, while others may have granted it. The ADF will make the final decision, normally it uses a restrictive algorithm: if only one module rejected the call, the call will be rejected. Next, the ADF communicates its decision to the AEF. The ADF will be called by the AEF again after completion of a granted system call and the ACI will be updated accordingly.
In short: the AEF intercepts calls and either allows or denies them, the ADF is the part where the decisions are made and the ACI is used for storage of status data and configuration items.