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
Table of Contents
Role Compatibility (RC)
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 objects
- Can select the type of the next created filesystem object with rsbac_rc_select_fd_create_type() system call, if it has SELECT right on that type
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 | List of rights to types | Compatible file/dir types by request types (which type may be accessed with which request) |
| type_comp_dev | List of rights to types | Compatible device types by request types |
| type_comp_process | List of rights to types | Compatible process types by request types |
| type_comp_ipc | List of rights to types | Compatible process types by request types |
| type_comp_scd | List of rights to types | Compatible SCD types by request types |
| type_comp_user | List of rights to types | Compatible user types by request types |
| type_comp_group | List of rights to types | Compatible UM group types by request types |
| type_comp_netdev | List of rights to types | Compatible network device types by request types |
| type_comp_nettemp | List of rights to types | Compatible network template types by request types |
| type_comp_netobj | List of rights to types | Compatible network object types by request 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 (use no_create to disallow creation, needs CREATE right for chosen type) |
| def_fd_ind_create_type | File/dir type number or special value | Type of new files/dirs per type of the dir they are created in (use def_fd_create_type, if not set for dir's type, 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) |
| def_user_create_type | USER type number or special flag | Type of new RSBAC users, if created by this role (use no_create to disallow creation, needs CREATE right for chosen type) |
| def_group_create_type | GROUP type number or special flag | Type of new RSBAC groups, if created by this role (use no_create to disallow creation, needs CREATE right for chosen type) |
| def_unixsock_create_type | FD type number or special flag | Type of new Unix sockets (UNIXSOCK target), if created by this role (needs CREATE right for chosen type) |
| boot_role | true or false | Is this the role for kernel and booting? |
| req_reauth | true or false | Require reentering user's password to actively change into this role with sys_rsbac_rc_sys_change_role() (needs RSBAC UM) |
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 gets an 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.
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 |
Special Access Rights
RC maintains several special access rights to types, which do not exist in the other modules.
| Special Right | Meaning |
|---|---|
| ADMIN | Change name of type |
| ASSIGN | Assign type to object |
| ACCESS_CONTROL | Grant or revoke standard (not in this list) RSBAC rights to this type |
| SUPERVISOR | Grant or revoke rights in this list to this type |
| MODIFY_AUTH | Change AUTH module settings for objects with this type |
| CHANGE_AUTHED_OWNER | Setuid to last authenticated user with this type |
| SELECT | Select this type with sys_rsbac_rc_select_fd_create_type() for next created filesystem (FD) object |
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
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.
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
RC contains 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 (see above). 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)
- 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!
Table of Contents: RSBAC Handbook
Back: Security Models