documentation:rsbac_handbook:security_models:rc
=>  Releases

Current version
Git/Snapshot: 1.5.3
Release: 1.5.0

Latest Snapshots
Produced after each commit or rebase to new upstream version

GIT
RSBAC source code, can be unstable sometimes

=>  Events

No events planned

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

//
documentation/rsbac_handbook/security_models/rc.txt · Last modified: 2009/01/13 10:51 by 127.0.0.1

documentation/rsbac_handbook/security_models/rc.txt · Last modified: 2009/01/13 10:51 by 127.0.0.1
This website is kindly hosted by m-privacy