RSBAC is module based. It means every decision module implements a different kind of policy. If you need MAC, ACL, just User Management, or even writing your own, the choice is yours!

Everything in RSBAC is implemented as a module, with a very flexible and easy to use framework.

Remember that modules often represent a security proven model, it is easy to confuse both words. Fortunately (or not), modules and models usually represent the same thing in RSBAC, so making a mistake is not a terrible thing.

Note: The Security Modules are highlighted in red

In the following table, you can find a summary of every available module.

The Code Name is the name RSBAC uses to identify that module.

The Use column helps out if you are not sure of what modules to use:

• Always: always turn it on.
• Likely: you most probably want this module.
• Optional: it is up to you, you may not need this module.
• Unlikely: this module is rarely used.

The Short description column links to a description of the module in the current page.

The In depth description column links to a section completely dedicated to this module, explaining the functionality and usage in details.

The AUTH module is a strongly recommended part of RSBAC. It provides basic functionality needed by all other modules.

AUTH controls which process can change to which user ID (UID). Together with the RSBAC User Management (or the future auth daemon) it can restrict all user IDs used on the system to AUTHenticated users and the ones that have been preset with so-called AUTH capabilities.

If enabled in RSBAC kernel configuration, the AUTH module also controls the user and group ID on the filesystem.

AUTH permissions can be issued on two levels:

• You have to give a list or range of UID's a process may assume (its “capabilities”, e.g can change UID to 100 and 101 only)
• A process is allowed to assume any UID it asks to (with the option “auth_may_setuid”).

This second option is just like giving the process all possible UID capabilities

You can configure the AUTH module using the command line utility auth_set_cap.

By default this utility will only accept calls from the user Security Officer (defaults to UID 400)

This model should always be used, because it controls which users can work on the system. All other models depend on proper user identification, which can only be enforced with AUTH model.

For more information about this model, please see the AUTH page.

As the name implies, RC is a role based model:

Every user has a default role, which is inherited by all of his processes. The role defines which access to objects of certain types will be granted or denied.

To use an analogy, it is like playing a role in a theater. You have strict, defined rules of what your character should be doing or not, but it's up to you to interpret it.

If you were to play a webserver role, RSBAC would ensure that you are only able to read your configuration and html files, write to your temporary directory and maybe execute php.

Whichever process has been started by the webserver will run in that role and won't be able to do anything more on the system.

For more information about this model, please see the RC page.

Access Control Lists are specifying which subject (a user, RC role or an ACL group) may access which object (of a target type) using which requests (usual RSBAC requests and some special ACL requests). ACL are precise and allow a fine policy tuning.

ACL are tradionally used for a fine grained filesystem access (in comparison to the standard Linux single user and group, read/write/execute based ACL), but can also be applied to RC roles in RSBAC.

This model should be used whenever you have individual subjects and objects, which cannot easily be grouped into roles and types for RC model, or if you need strong (possibly discretionary) access control with individual user groups. However, individual ACLs can be confusing. Try to use time-to-live settings for all temporary changes.

For more information about this model, please see the ACL page.

The MAC model associates processes with the security level of the user running them.

It then grants read access to other processes, files or devices which have the same or lower security level only, never above. Write access is limited to objects that are on the same security level only. MAC cannot be overridden without special privileges.

The RSBAC MAC implementation is a more fine-grained extension of the Bell and LaPadula model, which is better suited for use in a Linux environment.

For more information about this model, please see the MAC page.

The PaX or Pageexec kernel security extension contains several measures against usual ways to programs using the memory representation of the kernel. For example PaX can separate the code and data memory areas and randomize addresses.

In a standard PaX installation, you can change theses settings on a per file basis by writing specific information in the program header. As a direct side effect, it changes the original program file. Instead, RSBAC administrates the PaX flags in a consistent way and with a central backup facility.

The RSBAC based settings never touch the program file, so they avoid integrity checker alarms, missing flags when you update the program, ease system updates, and most importantly, avoid a write access to these binaries.

If you use this module, make sure to disable header marking and to enable direct MAC system integration in the PaX kernel configuration. Also do not use “paxctl” or similar programs which won't work. Use the RSBAC utilities instead.

More PaX information and the PaX patches are available from the PaX homepage at http://pax.grsecurity.net and pre-releases at http://grsecurity.net/~paxguy1.

This module should be used whenever the (very recommended) PaX kernel extension is also used.

The RSBAC "enhanced" kernel ship with the PaX kernel extension by default.

DAZ will be removed in some future release.

This is not really an access control model, but rather a system protection module against malware. Execution and reading of malware infected files can be prevented.

The first task of this module, is to protect the system from the antivirus scanner itself. On a standard system, the scanner must have a complete system access. It means that you have to trust the scanner, and that a bug in the scanner can potentially compromise the whole system.

For more information about this model, please see the DAZ page.

User Space Decision Facility (UDF, new in 1.4.8) is not a decision module by itself, but a helper to call user space decision programs. It is targeted for malware scanning, but could also be used for other purposes.

UDF allows to register a user space program (checker) through RSBAC proc interface or kernel parameter rsbac_udf_checker=/path/to/prog to be called for decisions, e.g. a virus scanner wrapper. The request types leading to a check are listed in include/rsbac/adf_main.h in the macro RSBAC_UDF_REQUEST_VECTOR. Checking results may optionally be cached, see CONFIG_RSBAC_UDF_CACHE kernel config switch.

To avoid loops, the checker program should be marked as udf_checker to bypass checking for this program. Only UDF security administrators are allowed to modify udf_checker or udf_checked.

The checker program has to exit with 0 for “allow”, 1 for “deny”, 254 for “temporary failure, allow” (do not cache) or 255 for “temporary failure, deny” (do not cache). Any other exit code is undefined, but for now treated as “deny”. If the checker got killed by a signal, it is treated as “temporary failure, deny”.

Please note that the checker is started as user mode process, but with attributes inherited from kernel context. E.g. its RC role is the kernel role, explicitly set a force role for the checker to have different rights.

In the Linux kernel, all root special rights are grouped into a so-called Posix Capabilities list. It can be network administration capabilities, or simlpy full filesystem access. The RSBAC CAP module let you define a minimum and maximum capability set for both users (including root) and processes.

It is important to understand that: program settings override the user settings, and minimum settings override the maximum settings.

This model should be used whenever you have to do something which is usually forbidden by standard Linux access control, or if you have to run a root daemon, but want to restrict its list of Posix capability.

For more information about this model, please see the CAP page.

All Linux kernels provide the chroot system call to confine a process in a subdirectory. However, it still run with every usual privileges, especially when running as root. There are also several known ways to break out if the chroot environment. Finally, you must copy every require program, file, and libraries into the subdirectory for the program to run properly. It is not always a simple task.

To solve it, the JAIL module provides a superset of the FreeBSD jail functionality (except individual kernel level hostnames).

Use this module for simple service encapsulation, where chroot environments are applicable, but insufficient. Please do not forget that filesystem objects within the environment must still be protected separately, e.g. with JAIL Linux capability restrictions or using another model. As usual, the JAIL module only places further restrictions, so all other modules can be used independently.

For more information about this model, please see the JAIL page.

The Linux kernel allows us to specify the resource limits for processes, for example:

• CPU time used
• Memory used
• Number of processes allowed for the same user
• etc.

Unfortunately, these settings cannot be administrated properly with the default Linux implementation.

The RES module solves this issue by administrating the Linux resource settings, for both users and programs.

We define minimum and maximum values for each resource, and apply them at execute time or when the user ID change. The minimum values will override the maxium values.

To set default values which will affect all users by default, use the special user ID 4294967292 (-4, ALL_USERS in RSBAC). It's the maximum user ID and is reserved for this use.

The RES module should be used whenever you want to mandatory enforce resource limits.

File Flags is a model which allows you to easily set attributes on files or directories, like read only, append only, write only, execute only, “no delete or rename”, etc.

The settings will be enforced for all users including root (with an exception - users which belong to the FF role role_admin are not restricted by the no_search flag), so this model is recommended only for global settings.

For more information about this model, please see the FF page.

These modules have been removed

This model should be used for storage and processing of personal data. To protect system data without the administration overhead of treating them as personal data, other models (FC, SIM, RC or ACL) are the ones to be used.

It was presented on the 17th National Computer Security Conference in Baltimore, USA, in 1994 by its developer Simone Fischer-Hübner. It follows the rules of the Federal German Privacy Law and the EU directive on privacy.

The model and implementation in RSBAC are described with details in our paper at the NISS 98 Conference.

The main concept being the module, as the name says, is enforcing privacy, as defined by the above directives on privacy. Confidentiality, integrity and availability are maintained for your personal data and transactions procedures by defining the necessary accesses.

System control data, like General Settings or Authentification Information can only be protected by declaring them as personal data. When you cannot do this, the data cannot be protected.

FC can be easily expressed with RC model, so it is kind of obsolete. The RC default settings are very similar. You should only use this model to get some experience before using more powerful models.

The role based model of functional control assigns one role to each user, for example:

• General User
• Security Officer
• System Administrator

Every object gets a category, for example:

• General
• Security
• System Object

The security officer states which roles are compatible with which object categories, which means, the user in role x can access objects in the category y. The security system enforces these settings.

The file/dir/fifo attribute object_category can be inherited from the parent dir.

There is also a simple version of the Functional Control implemented in RSBAC, which only protect system data and security relevant data. It already enforces separation of duties between theses two special roles. Without distinction between different access modes this model should only be used as part of a combined system.

SIM can be easily expressed with RC model, so it is kind of obsolete. You should only use this model to get some experience before using more powerful models.

The Security Information Modification model only allows write access to objects marked as “Security Data” for users labelled as “Security Officers”.

The file/dir attribute data_type can be inherited from the parent dir.

Like the Functional Control model, SIM should only be used in combination with others. The security relevant information can still be protected against tampering by system administrators, which is more than Unix ™ style access control can.

Table of Contents: RSBAC Handbook
Previous: Architecture and Implementation
Next: Installation