Releases
Current version
Git/Latestdiff: 1.5.6
Latest Snapshots
Produced after each commit or rebase to new upstream version
GIT
RSBAC source code, can be unstable sometimes
Events
No events planned
This is an old revision of the document!
Table of Contents
The original RC module has been added in RSBAC version 1.0.8.
Note that the number of roles and types is only limited by their 32 bit integer index number and system resources.
Roles can be changed if the process owner changes, via a system call (only “compatible roles” will be allowed), or by the execution of a specially marked executable (using initial_role or force_role. Warning, in that case, the role is forced and won't need to 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
- Entries for type setting behaviour on execution and change of process owner
- A “no_create” special value, which disallows creation of the new objects
Please also see the detailed RC model description in the Nordsec 2002 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 | Array of 64 vectors of 64 bit each (64×64 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 (64×64 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 (64×64 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 (64×64 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 (64×64 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.
From v1.2.3, there are also USER type compatibility settings, along with user type definitions and a default_user_create_type field, and from v1.2.4, there is a default_group_create_type. Both are very useful with RSBAC based user management, which has been added in v1.2.4.
Version v1.2.3 also adds a role flag boot_role. The first role with this flag set is used to start the system. If no such role is available, the default role of user 0 (root) is used like in previous versions.
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.
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.
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
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, five pre-defined roles are set up:
- General User (0)
- Role Admin (1)
- System Admin (2)
- Auditor (3)
- Boot Role (999999)
The first three pre-defined role settings have been derived from the hard-wired settings in the FC module.
When started without type definitions, three types per target are set up:
- General (0) (default, which is also used as default value for all type attributes)
- Security (1)
- 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 which are designed to get you started. They can be changed like any other role! You may easily lock yourself out if you change them without knowing exactly what you are doing. The best choice is to copy a role first and modify the new one.
Maintenance and soft mode will allow you to modify roles, even if you turned their 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.
Following the least-privilege rule, you can make the default user role 0 a dummy one, and set the role for every user explicitely. This way nobody gains anything by adding new users.
Time limits
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
Newer RC versions (v1.0.9a+) contain a sophisticated model of duty separation. For this to work, 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:
– 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):
– 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.
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 processes, and not only on users. The role and type abstraction makes administration much easier than individual settings!