RSBAC

RSBAC
Other names	Rule Set Based Access Control
Original author	Amon Ott
Developer	Amon Ott
Release	5 January 2000
Written in	C
Operating system	Linux
Type	Patch (computing), security
License	GNU GPL
Website	www.rsbac.org
Repository	git.rsbac.org

RSBAC (Rule Set Based Access Control) is a free and open-source (GNU GPL ) Linux kernel patch, focused on security. It extends security checks made by the original kernel to allow for a more fine-grained access control.

RSBAC deploys a security framework inside the kernel to control actions requested by processes. Therefore, RSBAC does not improve security in itself, but it permits to define precise rules when interacting with operating system objects.

It implements a modular architecture, allowing the use of different security models, such as access-control lists (ACL) and role-based access control (RBAC). Multiple modules can be combined to adjust the system configuration.

RSBAC supports the latest long-term support kernel versions.

Structure

Requests

Access control in RSBAC is triggered inside system calls, thanks to custom hooks. To apply access control, RSBAC formalizes requests in three parts :

• the subject, that is the process making the request. A process acts on behalf of a user, which gives additional attributes to consider for access control.
• the request type, that is the action to make. The request type is mainly determined depending on the system call used.
• the target, that is the object on which the action is made.

RSBAC retrieves the configuration to check if the subject has the right to make this request type on this target and then allows or denies the request. The attributes to allow the request to the subject are different in the various security modules.

Targets are divided into separate categories, which are treated differently. The main ones are :

• FILE : files
• DIR : directories
• DEV : devices, identified by type, major number and minor number
• IPC : inter-process communication mechanisms, such as semaphores
• PROCESS : processes
• NETOBJ : network connections in a broad sense, including Internet Protocol or Netlink

Request types are varied and range from CLONE to allow forking of a process to MOUNT to allow mounting of a filesystem. The same request type can be used by multiple system calls : CHANGE_OWNER applies when changing the owner of a file or a directory with chown, but also of a process with setuid. Also, multiple request types can be used by a single system call, in particular open can request READ_OPEN, WRITE_OPEN, READ_WRITE_OPEN, APPEND_OPEN, or TRUNCATE.

List of RSBAC request types

• ADD_TO_KERNEL
• ALTER
• APPEND_OPEN
• CHANGE_GROUP
• CHANGE_OWNER
• CHDIR
• CLONE
• CLOSE
• CREATE
• DELETE
• EXECUTE
• GET_PERMISSIONS_DATA
• GET_STATUS_DATA
• LINK_HARD
• MODIFY_ACCESS_DATA
• MODIFY_ATTRIBUTE
• MODIFY_PERMISSIONS_DATA
• MODIFY_SYSTEM_DATA
• MOUNT
• READ
• READ_ATTRIBUTE
• READ_WRITE_OPEN
• READ_OPEN
• REMOVE_FROM_KERNEL
• RENAME
• SEARCH
• SEND_SIGNAL
• SHUTDOWN
• SWITCH_LOG
• SWITCH_MODULE
• TERMINATE
• TRACE
• TRUNCATE
• UMOUNT
• WRITE
• WRITE_OPEN
• MAP_EXEC
• BIND
• LISTEN
• ACCEPT
• CONNECT
• SEND
• RECEIVE
• NET_SHUTDOWN
• CHANGE_DAC_EFF_OWNER
• CHANGE_DAC_FS_OWNER
• CHANGE_DAC_EFF_GROUP
• CHANGE_DAC_FS_GROUP
• IOCTL
• LOCK
• AUTHENTICATE
• MOVETO
• GET_XATTR
• MODIFY_XATTR

Modes

RSBAC provides two modes : secure mode and softmode. In both modes, system call requests are evaluated. In secure mode, the access decision is applied as is. On the other hand, in softmode access is always granted even when a denied access decision is returned. Softmode is provided to be able to easily test the system and should not be used in a production system.

Modules

Role-based module (Role Compatibility)

When using this module, each process has a role. For each role, it is possible to define if the role is allowed to make a specific request on a given target. Access is then checked against the rules specified.

To further control access, each target category can be broken down into types. Types are groups of objects in the target category. FILE and DIR objects are grouped in FD types.

For example, multiple FD types can be defined : the first one would be applied for directories and files in /etc, a second one for those in /usr/bin and /usr/sbin, and a third one for every other location. The same role could then have different permissions on these three types. The rights each role has to the different types are called "type compatibilities".

With these mechanisms, the granularity of control is easily adjusted when configuring the system while providing an abstraction layer.

When executing a new program, the process receives its role either from the user executing the task or from an attribute defined on the executed file. This choice can be different for multiple programs on the same system.

A process has three main ways of changing its current role :

• by executing a file whose role attribute is different from the current role
• by changing the owner of the current process through a setuid()
• by calling a specific RSBAC system call

Roles to which a role can change with the RSBAC system call can be restricted through configuration. Such roles are said to be "compatible" with the former, which gives the Role Compatibility name to this module.

Access control lists (ACL)

With this module, rights to specific objects - such as a device or a file - is directly granted or restricted. Rights are granted to users or ACL groups of users (which are different from classical Linux groups). Default rights are defined for each target category (FILE, IPC ...).

Other modules

The MAC (mandatory access control) module implements a version of the Bell–LaPadula model which aims at multilevel security.

The UDF (userspace decision facility) delegates the access decision on a file to a process running in user space (rather than rules already defined in kernel space). In particular, it allows on-access virus scanning : when a user wants to access a file, the UDF process scans it and declines access if it is deemed malicious.

Some modules have features that are further from controlling access requests but still increase the system's security.

The AUTH (authenticated user) module restricts which setuid() calls are authorized for processes. It is a basic module that strengthens the protections of the other modules.

The CAP (capabilities) module permits to define the minimum and maximum Linux capabilities for executable files and users. In particular, the maximum powers of the root user can be limited.

The JAIL module confines a process by restricting its accesses on the system.

The RES (resource control) module defines minimum and maximum usage of system resources like CPU time, stack usage, or number of cores used.

The FF (file flags) allows to set flags on files to define some properties, such as declining deletion or renaming. The same features can be set up using other modules, but this one is simpler to configure.

Additional features

RSBAC offers the possibility to add its own module with custom rules through the REG (registration) interface, which permits the use of the same data structures as the other modules for performance.

The UM (User Management) system manages users and groups differently than the classical /etc/passwd, /etc/shadow and /etc/group files. It offers additional features such as one-time passwords and can fully replace the traditional system.

RSBAC can control access to network connections depending on multiple factors, such as the address family (e.g. a Unix socket or an IPv4 socket), the protocol family, the address and the port.

RSBAC provides some degree of separation of duty : privilege administration can be broken down to multiple users and RC roles.

Internal architecture

Access scheme

The RSBAC system architecture has been derived and extended from the Generalized Framework for Access Control by Marshall Abrams and Leonard La Padula. It is also inspired by an essay of La Padula where he describes how the GFAC could be implemented in a Unix operating system. It splits the access control into multiple components :

• the Access Enforcement Facility (AEF)
• the Access Decision Facility (ADF)
• the Access Control Rules (ACR)
• the Access Control Information (ACI)

The ACI describes the current state of the objects and subjects in the operating system. The ACR are the rules allowing or declining access to objects depending on both subject and object attributes.

When a subject requests access to an object through a system call, the AEF is called. It sends subject and object information to the ADF, which retrieves additional attributes in the ACI and access rules in the ACR.

The ADF checks whether the request is allowed thanks to the information collected and notifies the AEF with the check result. If needed, the AEF updates attributes in the ACI. Finally, the AEF grants or denies access for the subject to the object.

For this access scheme to work, it is necessary to extend all (relevant) system calls with calls to the AEF and to define a clear interface between the AEF and the ADF. The request types are a great part of this interface.

Configuration storage

The RSBAC configuration is stored in a /rsbac.dat directory at the root of each filesystem. It is owned by root and has a Unix access mode of 000 (no one can read, write or execute). Moreover, the RSBAC kernel denies all accesses to these directories. Inside these directories, the configuration is split into multiple serialized files.

Internally, files and directories are referred to with their inodes, like SELinux and unlike AppArmor. This prevents circumventing access control with the help of hard links but can create some trouble during updates.

Dedicated hooks

To interact with the kernel structures, RSBAC uses custom hooks. It is therefore not a Linux Security Module (LSM). It is a deliberate choice of the project, as among other reasons they claim LSM hooks do not cover all RSBAC features and they expose low-level kernel structures, greatly increasing the attack surface.

Configuration

Kernel configuration

Most features in RSBAC can be enabled or disabled when configuring the kernel compilation. Doing so reduces the impact on the kernel performances if only needed features are enabled.

Access rules configuration

rsbac_menu command : main graphical (terminal user interface) configuration of RSBAC

RSBAC is configured through commands in userspace. Graphical (terminal user interface) tools are also provided for a visual way to set up the system.

It is possible to back up the full RSBAC configuration with a single command. This command will output a list of commands that should be called in order to set up the same configuration on an unconfigured system.

Example

Here is how to create a MyRole role with ID 10 for the RC module :

$ rc_set_item ROLE 10 name "MyRole"

In the same fashion, an FD (FILE and DIR) type MyFDType with ID 20 is created this way :

$ rc_set_item TYPE 20 type_fd_name "MyFDType"

It is then possible to add some rights to MyRole on MyFDType :

$ rc_set_item -a ROLE 10 type_comp_fd 20 READ_OPEN READ CLOSE

The attribute used is type_comp_fd because we are setting the type compatibility of role 10 to FD type 20.

Finally, MyRole is set as user1's role, and MyFDType as /etc's type with :

$ attr_set_user RC $(id -u user1) rc_def_role 10
$ attr_set_file_dir RC DIR "/etc" rc_type_fd 20

To make the configuration easier, a learning mode is provided for the AUTH, RC, ACL and CAP modules. Learning mode can be used both in secure mode and softmode. In this mode, when the ADF issues a denied access decision, the rights needed for the request to instead be allowed are added to the subject rights.

/proc/rsbac-info interface

RSBAC sets up a custom directory in the /proc (procfs) pseudo-filesystem.

It is used to present some information and statistics. Some parameters can also be changed directly by writing to the /proc/rsbac-info/debug file, such as switching between secure mode and softmode. Those parameters can also be set using kernel command line parameters.

Logging

By default, RSBAC only logs denied access requests. It is possible to change this behavior for each target category to log both granted and denied requests, or none. The RSBAC log is available at /proc/rsbac-info/rmsg and in the system log. An option enables remote logging.

Difference to RBAC

Role-based access control (RBAC) is an access control model that theoretically defines how rights are granted to subjects through roles.

On the other hand, RSBAC is an access control framework, which sets up an architecture to apply arbitrary access control rules in an operating system. These rules are defined inside the RSBAC modules. Modules can be seen as rule sets, giving the Rule Set Based Access Control name to RSBAC.

See also

• Computer security
• Linux Security Modules
• Security-Enhanced Linux
• AppArmor
• Access control list
• Attribute-based access control (ABAC)
• Context-based access control (CBAC)
• Discretionary access control (DAC)
• Graph-based access control (GBAC)
• Lattice-based access control (LBAC)
• Mandatory access control (MAC)
• Role-based access control (RBAC)
• Capability-based security
• Risk-based authentication

External links

• Official website