Rule Set Based Access Control - Models

| # Rule Set Based Access Control (RSBAC) for Linux - Models

# RSBAC Models

RSBAC 1.2.0 includes the following models:

- Module Registration (REG) (not really a model)
- Mandatory Access Control (MAC)
- Functional Control (FC)
- Security Information Modification (SIM)
- Privacy Model (PM)
- Malware Scan (MS)
- File Flags (FF)
- Role Compatibility (RC)
- Authentification (AUTH)
- Access Control Lists (ACL)
- Linux Capabilities (CAP) (new in 1.2.0)

## Mandatory Access Control (MAC)

### Bell-La Padula

#### Definitions

The Bell and La Padula Model describes access by active entities, called subjects, to passive entities, called objects. One entity can, depending on type of access, be in both roles.

From the distinction between read and write access four modes of access can be distinguished: neither read nor write (execute, e), read only (read, r), write only (append, a) and read-write (write, w). The set of all access types is named A.

#### System States

Each current access of a subject Si to an object Oj in mode x is treated as a triple (Si, Oj, x). All these triples together form the set of current accesses b.

Objects are structured according to the Father-Son-Principle and build a hierarchy H of one or more hierarchically ordered, independent trees.

All authorized accesses of all subjects to all objects are held in the matrix M. Each cell Mi,j of M thus contains a subset of A with authorized accesses of Si to Oj.

A security level is a pair (Security Classification, Set of Categories). A security classification is a value out of a hierarchy, e.g. public, confidential, secret, top secret. A category is a formal assignment to a work area.

One entity with security level (S1,C1) dominates another entity with (S2,C2), if S1>=S2 and C1 is a superset of C2. The property dominates over all entities builds a partial order D.

The assignment of security levels to subjects and objects, the classification function F, is a triple (fS, fO, fC) of security level assignment functions. fS(Si) is the maximum security level of subject Si, fO(Oj) the security level of object Oj and fC(Si) the current security level of subject Si. Thus for subjects maximum and current security level are distinguished.

For all Si fS(Si) must always dominate fC(Si).

A state z of the model is a tuple (b, M, F, H). A system is a sequence of (request, decision, next state) with initial state z0.

#### Security Properties

The first property to be maintained is the simple security property (no read-up). This property states that a subject Si may have read access to an object Oj ((Si,Oj,r) or (Si,Oj,w) is a current access), if Si dominates Oj.

Figure 1: Illegal information flow in Bell-La Padula model.

To prevent copying of an object to a lower security level by a malicious subject, the *-property (no-write-down) must be maintained. This property states: If a subject Si has current read access to an object O1 and current write access to an object O2, then O1 must be dominated by O2 (O1 has a lower security level than O2). Thus information flow is restricted to upwards.

As a strict accordance to the *-property would significantly reduce the usability of the system, some subjects can be marked as trusted subjects without *-property restriction.

Access control by the matrix M of authorized accesses by subjects to objects is called discretionary access control, its security property is called ds-property. The current access must always be in the set of authorized access in its matrix cell.

All properties and security levels must be mandatorily enforced by the system. Every property is added to the other ones and can never reduce system security. A state that fulfils all properties is called secure.

#### Decision Rules

The three properties lead to the following rules for access control decisions:

A current access (Si,Oj,x) is only granted, if the following conditions are met:

1. ss-property: Si dominates Oj, if x = r or x = w (x contains read access).
2. *-property: Si is trusted or
   1. Oj dominates current level of Si, if mode = a
   2. level of Oj is equal to current level of Si, if mode = w
   3. current level of Si dominates level of Oj, if mode = r
3. ds-property: x is in cell Mi,j of matrix M of authorized accesses

#### Functions

To use the defined security system state transition functions are necessary. These functions must provably change a secure state to another secure state, according to the decision rules. So induction can be used to proof every reachable state to be secure.

A complete set of those functions can be as follows:

- Change set b of current accesses:
  - get-access(): add triple to set b
  - release-access(): remove triple from b
- Change matrix M of authorized accesses:
  - give-access-permission(): add access mode to a cell of M
  - rescind-access-permission(): remove access mode from a cell of M
- Change classification function F:
  - change-object-level()
  - change-current-level()
- Change object hierarchy H:
  - create-object(): create leaf object
  - delete-object-group(): remove object with all subobjects from tree

#### Evaluation

The Bell-La Padula model only treats confidentiality aspects. Integrity, availability and privacy of data are not protected. E.g., a subject on lowest security level can delete all data in all its categories, if it is not discretionally protected. Attacks like this can also happen without the user's knowledge, just think of malware or mistakes. Especially discretionary access control is liable to be attacked by malware.

The concept of trusted subjects which can only be implemented as users or user processes leads to further possibilities of attack by use of high level user accounts.

This model should only be used without additional protection, if confidentiality is the only issue or if data can be easily restored.

### Unix System V/MLS

The model of mandatory access control used in RSBAC is mostly the same as in Unix System V/MLS, Version 1.2.1. This operating system was developed in 1989 by the National Computer Security Center of the USA with classification B1/TCSEC.

Unix System V/MLS implements the Bell-La Padula model with some smaller changes, e.g. the ds-property is replaced by Unix style access control. Security levels with classification categories are maintained, simple-security-property and *-property are enforced. In contrary to Bell-La Padula writing is only permitted on the same level.

Bell-La Padula defined four modes of access:

- execute, E
- read, R
- write, W
- Append, A

This Unix system adds ten more modes, which mostly cover parts of the above modes:

- search in directory, S
- overwrite, O
- create, C
- link, L
- unlink (delete), U
- read file/i-node status, St
- change status, Ch
- send signal/kill, K
- read IPC, Ripc
- write IPC, Wipc

Subjects are processes, which inherit their owner's security level. Four types of objects are defined:

- File
- Directory
- Interprocess Communication Channel (IPC-Channel)
- System Control Data (SCD)

Request | Condition for access
--- | ---
R/S/E | S >= O
W(O/A) | S = O
C/L/U | S = Od
St | S >= O
Ch | S = O
Ripc | S >= O
Wipc | S = O
K | S = O

Figure 2: Access Control Conditions in System V/MLS

Figure 2 shows a summary of access control conditions. S means subject, O object, Od directory object and >= and = stand for dominates and has same level. Read and write on directories mean access to entries, open is not possible.

### The RSBAC MAC implementation

The Unix System V/MLS model has been changed to fit into the RSBAC access request scheme, which knows more than 30 types of access. Also, write-up is implemented in the original way, so that you can always write to all higher levels. From version 1.1.1 onwards, writing is only allowed on the same level.

Since administration depends on the role security officer, role based functions had to be added. These restrict all changes to the classification of subjects and objects and role assignments (setting of MAC attributes) to security officers.

The security_level attributes used in RSBAC are what is usually called security classifications. Categories, limited to a number of 64 for efficiency reasons, have been added in RSBAC 1.0.8. From 1.0.9b, the number of security_levels has been increased to 253 (0-252, 8 Bit minus 3 special values).

The current security level (classification) and the current category set of a process are automagically adjusted as needed, if the mac_auto flag is on, which is the default value. However, mac_auto is turned off as soon as the process actively sets its current level or category set.

*-property enforcement is done with upper and lower bounds, called min_write and max_read. These values are reset only on execution of another program, not at process forking/cloning time or closing of files, because only new execution empties the process memory space.

Please note that until version 1.1.0, all write accesses, e.g. creating a file in a DIR (CREATE on DIR target), lead to the min_write boundary to be adjusted. This can lead to very limited access. Therefore, from version 1.1.1 onwards, the once-only write accesses CREATE and DELETE do not adjust the min_write boundary, while MOUNT, APPEND_OPEN, READ_WRITE_OPEN, WRITE_OPEN and TRACE still do.

Devices are treated similar to files with security levels and categories, and all properties are enforced. However, these checks can be turned off (attribute mac_check), because the system might become unusable otherwise.

The MAC file/dir attributes security_level and mac_categories can be inherited from the parent dir. For the security level the value to indicate inheritance from parent is 5 (4 is used internally), for categories it is the empty set (all bits 0). From version 1.0.9b, the security_level special values have been raised by 249, now being 254 and 253.

### RSBAC MAC-Light

Stanislav Ievlev and me added a MAC option called MAC-Light to make the MAC module easier to use. Changes are:

1. File/Dir/Fifo object creation is always granted
2. Every user may mount, if levels are sufficient (used to be limited to system administrators)

### When to use this model

The MAC model should be used, if you need a conceptually proven model for confidentiality. However, it is quite difficult to use in a typical Linux environment.

## Clark-Wilson Integrity Model (CWI)

This model has been dropped from the RSBAC agenda, and will not be implemented, unless somebody proves urgent need for it.

## Functional Control (FC)

The role based model of functional control assigns one role to each user, e.g. general user, security officer or system administrator. Every object gets a category, e.g. general, security or system object.

The security officer states which roles are compatible with which object categories, or in other words, users in which roles can access objects in which categories. The security system enforces these settings.

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

The functional control model can in the simple version that is implemented in RSBAC only protect system data and security relevant data, but it already enforces separation of duties between the two special roles. An extension to more and more flexible roles could build this to a strong model. Without distinction between different access modes this model should only be used as part of a combined system.

FC can be easily expressed with RC model, so it is kind of obsolete. The RC default settings are very similar to this model.

You should use this model only to get experience as a base for other, more powerful models.

## Security Information Modification (SIM)

This role based model protects data of type security information. Only users with role security officer get write access to those objects.

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

Like the functional control this model should only be used in combination with others. Otherwise the security relevant information can still be protected against tampering by system administrators, what is more than Unix style access control can.

SIM can be easily expressed with RC model, so it is kind of obsolete.

You should use this model only to get experience as a base for other, more powerful models.

## Simone Fischer-Hübner's Privacy Model (PM)

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.

The model and its implementation in RSBAC are described in detail in our paper for NISS 98 Conference.

The model focus lies on privacy. Confidentiality, integrity and availability are maintained for personal data and transaction procedures by the definition of necessary accesses.

System control data like general settings or authentification information can only be protected by declaring them as personal data. If this is not possible for some data, they cannot be protected.

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, another model, e.g. FC, SIM, RC or ACL, should be used.

Use PM model, if you want to process personal data and need adequate protection.

## Malware Scan (MS)

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

This model should be used, if data, especially programs, are transferred from other systems to prevent a widespread malware infection. However, only malware known by the scanner algorithm can be be detected. On Linux this is the bliss virus in variants A and B and a few DOS viruses. Platform independent macro or java viruses will have to be included later.

Currently, this is only a working demonstration model, because too few viruses are detected. However, it is rather simple to add more scan strings, if you want to. From version 1.2.0, there is a generic interface to add other scanning engines.

For more details see our paper on Approaches to Integrated Malware Detection and Avoidance (34K) for The Third Nordic Workshop on Secure IT Systems (Nordsec'98)

## File Flags (FF)

This model defines some access flags for files, fifos (new in 1.1.1) and dirs. Currently, the following flags are supported:.

Flag | Checked for | Notes
--- | --- | ---
execute_only | FILE |
search_only | DIR |
read_only | FILE, FIFO, DIR |
write_only | FILE, FIFO |
secure_delete | FILE | File is blanked on delete and truncate (ext2, msdos/vfat, minix only)
no_execute | FILE |
no_delete_or_rename | FILE, FIFO, DIR | new in 1.1.1, not inherited
append_only | FILE, FIFO | new in 1.1.2, write accesses are limited to APPEND_OPEN and WRITE, read accesses are allowed
add_inherited | FILE, FIFO, DIR | not inherited

These flags are checked on every access to the given target types. Only users in system_role 'security officer' can change the flags.

The add_inherited flag is special: If set, the parent dir's flags are added (or'd) to the target's own flags. Inheritance is on by default. Attention: the flags no_delete_or_rename and add_inherited cannot be inherited, they must always be set explicitely!

Please note that the attributes are independent from each other and restrictive: All attributes that are set are applied, e.g. execute_only and no_execute together (or read_only and write_only) lead to no access.

Flags that are only checked for some target types are ignored for the other ones. This can be used to set e.g. search_only and execute_only on a dir - you can SEARCH (not READ!) in the dir and EXECUTE files in it, but nothing else.

Example1: Set write_only on a logging dir. All log files created in that dir inherit the write_only flag, thus the log can never be read unless the flag is removed.

Example1b: Set append_only on a logging dir. All log files created in that dir inherit the append_only flag, thus the log can be read, but writing can only append to the file, unless the flag is removed. Add flag write_only, if the files should not be read either.

Example2: Set no_execute on /home. All executables below that dir inherit this flag, thus no user can execute files from her home directory, unless the flag is removed.

Example3: Set no_delete_or_rename on /home. User home dirs below can be added, removed and individually protected, but the parent dir /home cannot be moved or replaced to fake other home dirs for most users.

File Flags should be used, if you need global access settings which are valid for all users.

## Role Compatibility (RC) - Until v1.0.9-pre3

Attention: This is the description of a rather old RC version. Please go to the new description for recent RSBAC versions!

This is a powerful and flexible role based model. It defines 64 RC types for each target type (File/Dir, Device, Process, Inter Process Communication, System Control Data) and 64 RC roles to access them. The RC module has been added in RSBAC version 1.0.8.

Please also see the RC model description in the RC-Paper.

### Role and Type Entries

Each role entry has the following fields:

Role Entry Field | Type/Values | Description
--- | --- | ---
name | string of 15 chars | Name of role
role_comp | 64 bit vector | Compatible roles (1 Bit per role) = roles process may change to without chown (setuid)
type_comp_fd | 64 bit vector | Compatible file/dir types (1 Bit per type)
type_comp_dev | 64 bit vector | Compatible device types
type_comp_process | 64 bit vector | Compatible process types
type_comp_ipc | 64 bit vector | Compatible IPC types
type_comp_scd | 64 bit vector | Compatible SCD types
admin_type | none, system or role admin | Role for RC role/type administration
def_fd_create_type | File/dir type number or special value | Type of new files/dirs
def_process_create_type | Process type number or special value | Type of new (forked/cloned) processes
def_process_chown_type | Process type number or special value | Type of process after a chown (setuid)
def_process_execute_type | Process type number or special value | Type of process after execute (start of a new program)
def_ipc_create_type | IPC type number or special flag | Type of new IPC channels

The admin_type entry denotes the RC administration rights: none = none, system admin = read-only, role admin = full. They do not give any other access rights, this is done with compatibility settings only.

Type entries have name fields (15 char strings). Only file/dir type entries have an additional boolean value type_fd_need_secdel, which indicates a need of secure deletion/truncation of files of this type.

SCD types are fixed and represent one area of accessible system data each. They are also used for administration rights, like adding modules or setting system time. SCD compatibility means accessability of the SCD facility.

### RC attributes

Each target apart from user targets gets a rc_type attribute to indicate its type. For files and dirs this field can hold the special value type_inherit_from parent to signal inheritance of the attribute.

User entries get an rc_def_role attribute, which is used to determine the process's initial role after each CHOWN (setuid).

Process entries also have an rc_role for the current role.

File/Dir entries have a field rc_force_role to specify a forced role, if this file is executed. This mechanism works similar to the setuid or setgid field in Unix file systems. The forced role can also have one of the special values.

### Special Values

The special values mentioned above are as follows:

Role Special Value | Meaning
--- | ---
role_inherit_user | use user's (process owner's) rc_def_role
role_inherit_process | use current rc_role of process (keep role)
role_inherit_parent | use current rc_role of parent dir or process

Type Special Value | Meaning
--- | ---
type_inherit_process | use current rc_type of process (keep role)
type_inherit_parent | use current rc_type of parent dir or process
type_no_create | creation of process/IPC is not allowed
type_no_execute | execution of other programs is not allowed
type_use_new_role_def_create | for process chown (setuid): use def_process_create_type of the new role

### Initial Configuration

When started without role definitions, three pre-defined roles are set up: General User (0), Role Admin (1) and System Admin (2). The pre-defined role settings are derived from the hard-wired settings in the FC module.

When started without type definitions, one type per target is set up. This is the default type General, which is also used as default value for all type attributes.

As usual in RSBAC, user root (0) has rc_def_role 2 and user 400 has rc_def_role 1 as predefined value in the default useraci contained in the admin tool package.

Please note: The pre-defined roles are normal roles designed to get you going. They can be changed like all other roles! You may easily lock yourself out, if you change them without knowing exactly what you are doing.

Still, the maintenance mode will allow you to modify roles, if you turned maintenance support for RC policy data on at kernel configuration.

To be secure, test your configurations with different role numbers and use rc_copy_role to copy them, if necessary.

## Role Compatibility (RC) - From v1.0.9-pre4 onwards

The older RC model has been much changed. Until v1.1.2, it defines 64 RC types for each target type (File/Dir, Device, Process, Inter Process Communication, System Control Data) and up to 64 RC roles to access them. The original RC module has been added in RSBAC version 1.0.8. From v1.2.0, the number of roles and types is only limited by their 32 bit interger index number.

RC is a role based model: Every user has a default role, which is inherited by all his/her processes. Based on the current role, access to objects of certain types is granted or denied. The role is changed by a change of the process owner, by the process via system call (only "compatible" roles allowed) or by execution of a specially marked executable (using force_role, need not be "compatible").

Creation of new objects is a special case in every access control model. Here, every role has entries for the types of new objects, as well as entries for type setting behaviour on execution and change of process owner. Additionally, all these entries have a "no_create" etc. special value, which disallows such requests.

Please also see the RC model description in the RC-Paper.

### Role and Type Entries

Up to v1.1.2, each role entry has the following fields:

Role Entry Field | Type/Values | Description
--- | --- | ---
name | string of 15 chars | Name of role
role_comp | 64 bit vector | Compatible roles (1 Bit per role) = roles process may change to without chown (setuid)
type_comp_fd | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible file/dir types by request types (1 Bit per type and request) = True/False value, which type may be accessed with which request
type_comp_dev | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible device types by request types (1 Bit per type and request)
type_comp_process | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible process types by request types (1 Bit per type and request)
type_comp_ipc | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible process types by request types (1 Bit per type and request)
type_comp_scd | Array of 64 vectors of 64 bit each (64x64 Bit Matrix) | Compatible SCD types by request types (1 Bit per type and request)
admin_type | none, system or role admin | Role for RC role/type administration
def_fd_create_type | File/dir type number or special value | Type of new files/dirs (use no_create to disallow creation, needs CREATE right for chosen type)
def_process_create_type | Process type number or special value | Type of new (forked/cloned) processes (use no_create to disallow creation, needs CREATE right for chosen type)
def_process_chown_type | Process type number or special value | Type of process after a chown (setuid) (use no_chown to disallow creation)
def_process_execute_type | Process type number or special value | Type of process after execute (start of a new program) (use no_execute to disallow creation)
def_ipc_create_type | IPC type number or special flag | Type of new IPC channels (use no_create to disallow creation, needs CREATE right for chosen type)

From v1.2.0, all compatibility and admin/assign role settings are placed into separate list, but the other entries are unchanged. Also, NETDEV, NETOBJ and NETTEMP type compatibilities have been added to support the new network targets.

The admin_type entry denotes the RC administration rights for roles, types and RC specific attributes: none = no access, system admin = read-only, role admin = full. They do not give any object access rights, this is done with compatibility settings only.

Type entries have name fields (15 char strings). Only file/dir type entries have an additional boolean value type_fd_need_secdel, which indicates a need of secure deletion/truncation of files of this type.

SCD types are fixed and represent one area of accessible system data each. They are also used for administration rights, currently only auth_administration. SCD compatibility means accessability of the SCD facility. Additionally, the special SCD target 'other' is used to control requests with target type NONE.

### RC attributes

Each target apart from user targets gets a rc_type attribute to indicate its type. For files and dirs this field can hold the special value type_inherit_from parent to signal inheritance of the attribute.

User entries get an rc_def_role attribute, which is used to determine the process's initial role after each CHOWN (setuid).

Process entries also have an rc_role for the current role and a field rc_force_role to keep the executed program's rc_force_role value.

File/Dir entries have a field rc_force_role to specify a forced role, if this file is executed. This mechanism works similar to the setuid or setgid field in Unix file systems. The forced role can also have one of the special values (see below). The forced role value is copied into the process attributes for further use on CHOWN requests.

From version 1.1.2, FD entries also have a field rc_initial_role. This setting determines, which role will be used directly after start of execution. At the next setuid (CHANGE_OWNER on this process), it will be replaced by the value in rc_force_role.

rc_initial_role can also have the special (and default) value role_use_force_role, in which case the value from rc_force_role is also taken as initial value. This is the same behaviour as before this field was added.

### Special Values

The special values mentioned above are as follows:

Role Special Value | Meaning
--- | ---
role_inherit_user | use user's (process owner's) rc_def_role on CHOWN and EXECUTE (default forced role until 1.0.9a-pre2)
role_inherit_process | keep current rc_role of process on CHOWN and EXECUTE
role_inherit_parent | inherit value from parent object, e.g. parent DIR
role_inherit_up_mixed | keep current rc_role of process on EXECUTE, but use new process owner's rc_def_role on CHOWN (default forced role from 1.0.9a-pre3)
role_use_force_role | valid in rc_initial_role only, default value. Use the value from rc_force_role.

Type Special Value | Meaning
--- | ---
type_inherit_process | use current rc_type of process (keep type)
type_inherit_parent | use current rc_type of parent dir or process
type_no_create | creation of process/file/dir/IPC is not allowed
type_no_execute | execution of other programs is not allowed
type_no_chown | change owner of process is not allowed
type_use_new_role_def_create | for process chown (setuid): use def_process_create_type of the new role

### Initial Configuration

When started without role definitions, three pre-defined roles are set up: General User (0), Role Admin (1) and System Admin (2). The pre-defined role settings are derived from the hard-wired settings in the FC module.

When started without type definitions, three types per target are set up. These are the default type "General" (0), which is also used as default value for all type attributes, the type "Security" (1) and the type "System" (2). Only "General" is actually used in the default setting, but example compatibilities are set up for all types.

As usual in RSBAC, user root (0) has rc_def_role 2 and user 400 has rc_def_role 1 as predefined value in the default user ACI settings.

Please note: The pre-defined roles are normal roles designed to get you going. They can be changed like all other roles! You may easily lock yourself out, if you change them without knowing exactly what you are doing. It is mostly the best choice to copy a role first and modify the new one.

Still, maintenance and soft mode will allow you to modify roles, if you turned maintenance or soft mode support for RC policy on at kernel configuration.

To be safe, test your configurations with different role numbers and use rc_copy_role to copy them, if necessary.

To follow the least-privilege rule, you can make the default user role 0 a dummy and set the role for every user explicitely. This way nobody gains anything by adding new users.

### Time limits (from 1.2.0 onwards)

From version 1.2.0, you can set time-to-live values for compatible admin and assign roles as well as for all type compatibility settings. After the given time, the entry is deleted and further access is denied.

You can set ttl values with parameters -t, -T and -D in rc_set_item admin tool.

Warning: All ttl settings depend on the correct system time. You should take special care that it is always correct, if you are using this feature!

### Advanced Administration with separation of duties (from 1.0.9a-pre2 onwards)

Newer RC versions contain a sophisticated model of separation of duty. For this, the following additions have been made:

- New role vector admin_roles:
  Which roles a user in this role may administrate. Several role settings are further restricted by other rights, e.g. role_comp and type_comp_xx.
- New role vector assign_roles:
  Which roles a user in this role may read and assign to users and processes (process only, if MODIFY_ATTRIBUTE is allowed), and which compatible roles she may assign to administrated roles (if assign_roles contains all roles involved).
- Further restriction on changing user/process role: the old role must also be contained in your assign_roles vector. This way, a partial role assigner must always stay within a limited set of roles, and cannot affect users and processes in other roles.
- These new vectors may only be changed by old style Role Admins. If you set them at the beginning, and then remove all Role Admins, this separation is forever fixed (well, unless booting Maint kernel).

- New type access rights:

> ADMIN: Set/delete name, set need_overwrite for FD types

> ASSIGN: Assign this type to objects. You also need MODIFY_ATTRIBUTE on the old object type.

> ACCESS_CONTROL: Change normal (old) access rights to this type for your administrated roles

> SUPERVISOR: Change these new special rights to this type for your administrated roles.

> If no role has SUPERVISOR right to a type, the separation is forever fixed (again unless booting Maint kernel, or someone still has old style admin-type Role-Admin)

- Old roles and types (from older RC version) are automatically updated on the first boot of the new version. On update, Role Admins simply get everything new fully allowed. Caution: If you copy such an updated role, it also gets everything set for all roles and types!
  System Admins get assign right for their own role only, which means they are allowed to read their own role settings, but not to change anything.
  So you could reboot with new version, reset old admin_type to none for all roles and thus get your current administration settings fixed.

- The old style admin_type Role_Admin still works as before, to keep things simple for normal use.

### When to use RC model

This model should be used whenever subjects and objects can be easily grouped into roles and types, if you need a strong separation of duty, or if you need access control based on programs, not users. The role and type abstraction makes administration much easier than individual settings!

## Authentification Module (AUTH)

### Basics

This module can be seen as a support module for all others. It restricts CHANGE_OWNER on process targets (setuid) for a process: the request is only granted, if the process has either the auth_may_setuid flag set or the target user ID is in its capability set. The auth_may_setuid flag and the capability set are inherited on execute from the program file.

In other words: No setuid() variant system call will be allowed for any process running any program, unless the process (e.g. inherited from the program file) has either the flag auth_may_setuid set or an AUTH capability for the target uid.

A program file's capabilities can be set, if all modules grant a MODIFY_ATTRIBUTE request for A_auth_add_f_cap or A_auth_remove_f_cap. Process capabilities can only be added by other processes that have the auth_may_set_cap flag set, which is also inherited from their executed file.

This way an enforcement of daemon based authentification is possible, as well as a restriction of system daemons to a set of user IDs.

WARNING: If enabled without a login program having auth_may_setuid or a capability set and without a capability setting daemon, you will not be able to login to your system! Use kernel parameter rsbac_auth_enable_login in emergencies or at the first boot to set auth_may_setuid for /bin/login.

With AUTH enabled, system daemons which setuid to a normal user account, like portmap, mysql or whatever, need an explicit capability to do so. And they will only be able to use uids you granted.

### AUTH attributes

All Processes have two auth flags: auth_may_setuid and auth_may_set_cap with the above meanings. These are inherited by all child processes.

All files have the same two flags, which replace those of the process on execute of the file.

Files and processes also have capability sets with the same inheritance rules. Adding to and removing from capability sets is restricted by different access control schemes for processes and files: process caps can be set by any process, which has the auth_may_set_flag set, whoever may be the owner of the process. File flags are set on behalf of users by any program.

### Special Values

Up to version 1.0.9a, file capability sets can have the special value 65533 (UID -3), which is replaced by the owner of the process at the time the set is copied (execute time). Thus the process can come back to the original user ID after changing it. This value has been changed to 4294967292 (-3 again) in version 1.0.9b, which supports 32 Bit user ids.

### Initial Configuration

Initially, nothing is allowed. Thus you have to enable the login of the administrators, who can do everything necessary. This can be done with a maintenance kernel, setting appropiate values for all program files involved.

As a shortcut, you can use the kernel parameter rsbac_auth_enable_login, which sets auth_may_setuid (full rights to change process owner) for /bin/login. This behaviour is hardcoded in the AUTH module data structures.

### Administration

AUTH only restricts its administration, if this is enabled in the kernel configuration. Administration is limited to users with system_role security_officer, and all involved attributes are protected.

Every module can further restrict the AUTH administration, if it depends on proper authentification. See the configuration menu help pages for more info.

Administration is mostly based on the file and process attributes and the capability sets mentioned above. See instadm.htm for more details.

### When to use AUTH model

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.

## Access Control Lists Module (ACL)

### Basics

Access Control Lists specify, which subject (user, RC role or ACL group) may access which object (of an object type) with which requests (usual RSBAC requests and ACL specials).

If there is no ACL entry for a subject at an object, the rights to the parent object are inherited. Inheritance can be restricted by inheritance masks.

On top of the inheritance hierarchy there is a default ACL for each object type (FILE, DIR, ...).

To change the ACL of an object, you need the special right Access Control for this object. The special right Forward allows to give somebody else the rights you have, but you cannot revoke them afterwards.

Special right Supervisor includes all other rights, can never be masked out (unless allowed in kernel configuration) and can only be set by users who already have it. This right is set for user 400 in those default ACLs, which cannot be successfully read from disk at boot time, e.g. because of new installation.

All object types are supported. IPC, USER and PROCESS objects only have the common default ACL, which is always inherited to all objects of this type - these objects are too short-lived to administrate useful individual ACLs.

As of version 1.0.9a, there are an unchangeable ACL group Everyone (group 0), which by definition contains all legal users, as well as user defined groups.

Group management allows every user to define global and private groups without restriction. Global groups can be used by every user, private ones only by the group owner. Also, the group owner is the only one allowed to add or remove group members or to change the group settings name, owner and type. Since the owner can be changed, groups are transferable (thus making them possibly unaccessible for the original owner). This feature might become optional in future releases, because it can be used for attacks.

Group rights are added to user and role rights. As there is no global group administrator, every user can do the job of maintaining a sensible group structure, e.g. user secoff.

Just to mention: Similarities to other PC network systems may not be accidential... ;-)

### Time limits (from 1.2.0 onwards)

From version 1.2.0, you can set time-to-live values for all ACL entries and group memberships. After the given time, the entry is deleted and further access rights change according to the remaining settings.

You can set ttl values with parameters -t, -T and -D in the ACL admin tools.

Warning: All ttl settings depend on the correct system time. You should take special care that it is always correct, if you are using this feature!

### When to use ACL model

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.

## Linux Capabilities (CAP)

### Basics

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 programs. Program settings override user settings, and minimum settings override maximum settings.

This module can be used to

- restrict rights of programs run by root
- add root rights to normal user or programs run by them

in the standard Linux way. It is thus the only RSBAC module which directly interferes with existing Linux access control.

### When to use CAP model

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.

CAP is specially useful to give RSBAC administrators, who are not root, read access to all directories so that they can administrate there despite insufficient Linux access modes.

Note: If you only want to partially disable Linux access control for filesystem objects for all users, you might consider to use the generic RSBAC functionality provided for this purpose through the 'Allow disabling of Linux filesystem access control' kernel config option..

To top of page

Back to RSBAC Homepage -

Questions, tips, etc.

18-Mar-02, -ao