RSBAC for Linux consists of a number of patches for the kernel and a number of utilities. The patches enable us to connect to our framework and the utilities are needed to define and configure the security models.
The kernel patches intercept system-calls and reroute them through a chain of decision making modules. If all modules accept the execution of the intercepted system call the request is accepted and the system call will be executed. If on the other hand just one module refuses the call no other module can revert that decision and the call will not be executed. Denial of a call will be logged to allow auditing.
Each RSBAC security module implements a security model. You can mix and match security models at will to implement your security policy by simply loading the modules you need. oes When a process issues a request for a system call it is rerouted through the chain of RSBAC modules. Each module determines whether or not the call is allowed by applying the rules of its model within the scope of the configuration you provided. If some rule forbids execution of the call the RSBAC framework refuses its execution. Only if all modules permit the execution of the call it will be executed. Any module can deny access to a call, but never undo the denial of another module. This is called a 'restrictive design' and is an important part of the philosophy behind the RSBAC framework and hence its implementations. Denials will be properly logged. RSBAC provides extensive logging facilities, both to standard Unix (Linux) logging facilities and to a RSBAC specific secured circular buffer.
The RSBAC distribution comes with a set of ready to use modules along with the necessary tools to configure them. Just load the modules you need to provide the proper security level. If you need more you can also design and write your own modules and add them within the framework. The RSBAC system offers a flexible, extensible solution that enables extensive elimination of security risks.
Now, how does a module interact with the outside world? How is it configured? An few examples will clarify this. One of the modules implements additional attributes for (parts of) the filesystem (FF). For example this module could be used to deny execution of files in and under a certain directory. Another module verifies if a process is allowed to change its UID (the AUTH module). This module enforces that a program/process only has limited access to other user identities. On a regular system, if a program is owned by 'root' and has its setuid bit set it can change in and out of any user identity. By using the AUTH module you can restrict its access to a limited number of identities. Note that the program/process has no control at all over this: it can issue the system call to change into an identity but that call simply fails (which will be logged) if you have not explicitly allowed it.
Though you can load entire stacks of modules that often is not necessary at all. By loading a basic set of modules you can already achieve a major improvement of your systems security. The more complex models and modules (for example the Privacy Model PM) are used in very specific and exceptional situations. In general it is wise to restrict yourself to the use of modules whose functionality you fully understand.