2.7. Role Compatibility (RC)
2.7.1. Role Compatibility (RC) - Until v1.0.9-pre3
 | 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".
2.7.1.1. Role and Type Entries
Each role entry has the following fields:
Table 2-3. RC Role entry 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.
2.7.1.2. 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. forced role can also have one of the special values.
2.7.1.3. Special values
The special values mentioned above are as follows:
Table 2-4. RC Role special values
| 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 |
Table 2-5. RC Type special values
| 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 |
2.7.1.4. Initial Configuration
hen 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.
 | 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.
2.7.2. 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 can be 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 initial_role or 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" special value, which disallows such requests.
Please also see the RC model description in the (rather old) "RC-Paper".
2.7.2.1. Role and Type Entries
Up to v1.1.2, each role entry has the following fields:
Table 2-6. RC Role entry 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 IPC 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, eeds 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 global 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.
2.7.2.2. 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.
For NETTEMP targets, there are two RC type entries: rc_type and rc_type_nt. rc_type is inherited to the NETOBJ targets covered by this template, rc_type_nt is used for access to the template itself.
2.7.2.3. Special Values
The special values mentioned above are as follows:
Table 2-7. RC Role special values
| 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. |
Table 2-8. RC Type special values
| 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/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 |
2.7.2.4. Initial Configuration
From version 1.2.1, the following behaviour can be turned off by the global kernel boot parameter rsbac_no_defaults, which is useful for complete restore of a previous configuration from a backup script.
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.
| 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
2.7.2.5. 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.
| 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! |
2.7.2.6. 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 or switching RC off).
New type access rights:
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)- 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
Old roles and types (from older RC version) are automatically updated on the first boot of the new version (except from 1.1.2 to 1.2.0). 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.
2.7.2.7. 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 only on users. The role and type abstraction makes administration much easier than individual settings!