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

AUTH limits the user IDs a process can change to. Together with RSBAC User Management (or the future auth daemon) it can restrict all user IDs used on the system to AUTHenticated users and those that have been preset with so-called AUTH capabilities. The Linux implementation of the AUTH module handles requests from a process to change its UID. The configuration data defining if the call to change UID is granted or not is stored in the ACI. If enabled in RSBAC kernel configuration, AUTH module also controls effective and filesystem user IDs and group IDs.

AUTH permissions can be issued on two levels:

• You have to give a list of UID's a process may assume (its “capabilities”)
• 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)

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

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 be enforced with AUTH model.

The User Management in RSBAC is kernel based and complements or totally replaces Linux's user and group management subsystem.
Administration of users is enforced with granularity and flexibility.
There are several other advantages in the documentation.

For more information on this model, please see the UM 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 fully understand this model, please read the in depth explanation of the RC model.

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

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

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.

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, never above. Write access is limited to objects on the same level. MAC cannot be overridden without special privileges.

Protection decisions are not made by the object owner, they are enforced by the system.

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.

To fully understand this model, please read the in depth explanation of the MAC model.

The PaX or Pageexec kernel security extension contains several measures against usual ways of attacks on programs, for example by separating code and data areas and randomizing memory map addresses.

In a standard PaX installation, you can change theses settings on a per file basis by writing specific information in the program header. 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, 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 control kernel configuration. Also do not use “paxctl” or similar programs which won't work. Use rsbac_fd_menu or attr_set_* instead.

More PaX information and the PaX patches are available from the PaX homepage at http://pax.grsecurity.net.

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

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.

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

In Linux kernels, all root special rights are grouped in so-called Posix Capabilities, e.g. for network administration or full file access. The RSBAC CAP module allows to define a minimum and maximum capability set for both users and processes. Program settings override user settings, and minimum settings override maximum settings.

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

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 rights in the rough Posix capability scheme.

All Linux kernels provide the chroot system call to confine a process in a subdirectory. However, it still has all usual privileges, specially when run as root. Also, there are several ways to break out if the chroot environment.

The JAIL module provides a superset of the FreeBSD jail functionality (except individual kernel level hostnames).

For more information about this module, see the JAIL page.

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.

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 in 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 and setuid call time (CHANGE_OWNER on PROCESS targets). To set default values which will affect all users by default, you can set them to the special user ID 4294967292 (-4, ALL_USERS in RSBAC).

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

File Flags is a model which allows you to set attributes on files or directories, like “read only”, “append only”, “write only”, “execute only”, etc. The settings will be enforced for all users (with an expection - user in FF role role_admin is not restricted by no_search flag), so this model is recommanded only for global settings.

For more information about this model, and tables of all the possible attributes, please see the FF page.

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.

This model 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.

This 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.

These modules have been removed in the 1.2.5-pre code.

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.